|Main Archive Page > Month Archives > ipsec archives|
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of firstname.lastname@example.org Sent: Wednesday, October 28, 2009 21:19
To: email@example.com; firstname.lastname@example.org Cc: email@example.com; firstname.lastname@example.org Subject: [btns] RFC 5660 on IPsec Channels: Connection Latching
A new Request for Comments is now available in online RFC libraries. RFC 5660 Title: IPsec Channels: Connection Latching Author: N. Williams Status: Standards Track Date: October 2009 Mailbox: Nicolas.Williams@sun.com Pages: 31 Characters: 74209 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-btns-connection-latching-11.txt URL: http://www.rfc-editor.org/rfc/rfc5660.txt
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]
This document is a product of the Better-Than-Nothing Security Working Group of the IETF.
This is now a Proposed Standard Protocol.
STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
Requests for special distribution should be addressed to either the author of the RFC in question, or to email@example.com. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.
The RFC Editor Team
USC/Information Sciences Institute
Scanned by Check Point Total Security Gateway.