RFC 5660: IPsec Channels: Connection Latching
In plain English — editorial summary, not part of the RFC
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]
Document record
- Document ID
- RFC5660
- Published
- October 2009
- Authors
- N. Williams
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- sec
- Pages
- 31
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 4301Security Architecture for the Internet ProtocolUpdated
December 2005
- RFC 2401Security Architecture for the Internet ProtocolObsoleted
November 1998
- RFC 5755An Internet Attribute Certificate Profile for AuthorizationCurrent
January 2010
- RFC 5879Heuristics for Detecting ESP-NULL PacketsCurrent
May 2010
- RFC 5387Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)Current
November 2008
- RFC 5374Multicast Extensions to the Security Architecture for the Internet ProtocolCurrent
November 2008
- RFC 5996Internet Key Exchange Protocol Version 2 (IKEv2)Obsoleted
September 2010
- RFC 4945The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIXCurrent
August 2007
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?