[btns] RFC 5660 on IPsec Channels: Connection Latching

rfc-editor@rfc-editor.org Wed, 28 October 2009 19:22 UTC

Return-Path: <rfc-editor@rfc-editor.org>
X-Original-To: btns@core3.amsl.com
Delivered-To: btns@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 60FEB28C0CE; Wed, 28 Oct 2009 12:22:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.93
X-Spam-Status: No, score=-16.93 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id DBARTCtCJ0ho; Wed, 28 Oct 2009 12:22:01 -0700 (PDT)
Received: from bosco.isi.edu (bosco.isi.edu []) by core3.amsl.com (Postfix) with ESMTP id 7D30028C1A4; Wed, 28 Oct 2009 12:22:01 -0700 (PDT)
Received: by bosco.isi.edu (Postfix, from userid 70) id 54E06356BC1; Wed, 28 Oct 2009 12:19:11 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20091028191911.54E06356BC1@bosco.isi.edu>
Date: Wed, 28 Oct 2009 12:19:11 -0700 (PDT)
Cc: btns@ietf.org, rfc-editor@rfc-editor.org
Subject: [btns] RFC 5660 on IPsec Channels: Connection Latching
X-BeenThere: btns@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Better-Than-Nothing-Security Working Group discussion list <btns.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/btns>, <mailto:btns-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/btns>
List-Post: <mailto:btns@ietf.org>
List-Help: <mailto:btns-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/btns>, <mailto:btns-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2009 19:22:02 -0000

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

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute