[IPsec] FW: [btns] RFC 5660 on IPsec Channels: Connection Latching

Yaron Sheffer <yaronf@checkpoint.com> Wed, 28 October 2009 20:28 UTC

Return-Path: <yaronf@checkpoint.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BABAD3A68E7 for <ipsec@core3.amsl.com>; Wed, 28 Oct 2009 13:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.466
X-Spam-Level:
X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOdg8uXjcSl0 for <ipsec@core3.amsl.com>; Wed, 28 Oct 2009 13:28:36 -0700 (PDT)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 8AB8E3A68A6 for <ipsec@ietf.org>; Wed, 28 Oct 2009 13:28:34 -0700 (PDT)
Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n9SKSihu015442 for <ipsec@ietf.org>; Wed, 28 Oct 2009 22:28:45 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 28 Oct 2009 22:28:47 +0200
From: Yaron Sheffer <yaronf@checkpoint.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Date: Wed, 28 Oct 2009 22:28:44 +0200
Thread-Topic: [btns] RFC 5660 on IPsec Channels: Connection Latching
Thread-Index: AcpYA/tLnWOG/KVUTFOMm5skEcENZwACT0zg
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213D12@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [IPsec] FW: [btns] RFC 5660 on IPsec Channels: Connection Latching
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2009 20:28:36 -0000

-----Original Message-----
From: btns-bounces@ietf.org [mailto:btns-bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org
Sent: Wednesday, October 28, 2009 21:19
To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org
Cc: btns@ietf.org; rfc-editor@rfc-editor.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
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

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


_______________________________________________
btns mailing list
btns@ietf.org
https://www.ietf.org/mailman/listinfo/btns

Scanned by Check Point Total Security Gateway.