[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.
- [IPsec] FW: [btns] RFC 5660 on IPsec Channels: Co… Yaron Sheffer