Skip to main content

IPsec Channels: Connection Latching
RFC 5660

Revision differences

Document history

Date By Action
2022-01-20
(System) Received changes through RFC Editor sync (added Verified Errata tag)
2018-12-20
(System)
Received changes through RFC Editor sync (changed abstract to 'This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to …
Received changes through RFC Editor sync (changed abstract to 'This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by latching "connections" (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture.

Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS); thus, connection latching can add a significant measure of protection to BTNS IPsec nodes.

Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels. [STANDARDS-TRACK]')
2016-11-30
(System) Closed request for Last Call review by SECDIR with state 'Unknown'
2015-10-14
(System) Notify list changed from btns-chairs@ietf.org, draft-ietf-btns-connection-latching@ietf.org to (None)
2009-10-28
Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2009-10-28
Cindy Morgan [Note]: 'RFC 5660' added by Cindy Morgan
2009-10-28
(System) RFC published