IPsec Channels: Connection Latching
RFC 5660
|
| Document |
Type |
|
RFC - Proposed Standard
(October 2009; Errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5660 (Proposed Standard)
|
|
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]
Show full document text