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

Congratulations Nico!

And thanks to those that made this possible.

--julien

> -----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 12:19 PM
> 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