IPsec Channels: Connection Latching
RFC 5660
Document | Type | RFC - Proposed Standard (October 2009; Errata) | |
---|---|---|---|
Author | Nicolás Williams | ||
Last updated | 2018-12-20 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5660 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Tim Polk | ||
Send notices to | (None) |
Network Working Group N. Williams Request for Comments: 5660 Sun Category: Standards Track October 2009 IPsec Channels: Connection Latching Abstract 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. Status of This Memo 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. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Williams Standards Track [Page 1] RFC 5660 IPsec Connection Latching October 2009 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction ....................................................3 1.1. Conventions Used in This Document ..........................4 2. Connection Latching .............................................4 2.1. Latching of Quality-of-Protection Parameters ...............8 2.2. Connection Latch State Machine .............................9 2.3. Normative Model: ULP Interfaces to the Key Manager ........12 2.3.1. Race Conditions and Corner Cases ...................17 2.3.2. Example ............................................18 2.4. Informative Model: Local Packet Tagging ...................19 2.5. Non-Native Mode IPsec .....................................21 2.6. Implementation Note Regarding Peer IDs ....................22 3. Optional Features ..............................................22 3.1. Optional Protection .......................................22 4. Simultaneous Latch Establishment ...............................23 5. Connection Latching to IPsec for Various ULPs ..................23 5.1. Connection Latching to IPsec for TCP ......................24 5.2. Connection Latching to IPsec for UDP with Simulated Connections .....................................24 5.3. Connection Latching to IPsec for UDP with Datagram-Tagging APIs .....................................25 5.4. Connection Latching to IPsec for SCTP .....................25 5.5. Handling of BROKEN State for TCP and SCTP .................26 6. Security Considerations ........................................27 6.1. Impact on IPsec ...........................................27 6.2. Impact on IPsec of Optional Features ......................28 6.3. Security Considerations for Applications ..................28 6.4. Channel Binding and IPsec APIs ............................29 6.5. Denial-of-Service Attacks .................................29 7. Acknowledgements ...............................................30 8. References .....................................................30 8.1. Normative References ......................................30 8.2. Informative References ....................................30 Williams Standards Track [Page 2] RFC 5660 IPsec Connection Latching October 2009 1. Introduction IPsec protects packets with little or no regard for stateful packetShow full document text