IKEv2 negotiation for Bound End-to-End Tunnel (BEET) mode ESP secunet Security Networks AGantony.antony@secunet.comsecunet Security Networks AGsteffen.klassert@secunet.com
sec
IPSECME Working GroupIKEv2BEET
This document specifies a new Notify Message Type Payload for the
Internet Key Exchange Protocol Version 2 (IKEv2), to
negotiate IPsec ESP Bound End-to-End Tunnel (BEET) mode. BEET mode
combines the benefits of tunnel mode with reduced overhead, making it suitable
for applications requiring minimalistic end-to-end tunnels, mobility support,
and multi-address multi-homing capabilities. The introduction of the USE_BEET_MODE
Notify Message enables the negotiation and establishment of BEET mode
security associations.
Introduction
The Bound End-to-End Tunnel (BEET) mode, specified in the appendix B of
(Author's note: we propose to write BIZ document for RFC7402 Appendix B, an
updated document only for ESP BEET mode)
presents an optimized approach for deploying IPsec Encapsulating Security Payload
(ESP) by blending the benefits of tunnel and transport modes while minimizing
their overhead. The current, does not specify the negotiation process for
establishing BEET mode using the Internet Key Exchange Protocol Version 2 (IKEv2).
This document addresses this gap by proposing a new Notify Message Type Payload,
USE_BEET_MODE, specifically designed to enable the negotiation and establishment
of BEET mode security associations in IKEv2.
The introduction of a negotiation mechanism for BEET mode aims to enhance the
flexibility and applicability of IPsec, particularly in environments that demand
efficient end-to-end security with minimal overhead, such as mobile and multi-homed
networks. By providing a standardized method for negotiating BEET mode, this
document seeks to facilitate wider adoption and integration into the broader
IPsec framework.
Requirements LanguageThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
RFC 2119.Background
For over a decade, a minimalist IPsec tunnel mode, BEET, has been in use for
end-to-end security in HIP environments without IKE negotiation,
and in many environments using IKE negotiation using a private
Notification. (strongSWAN ref)
Once IKEv2 negotiation for BEET mode is standardized its potential for
enhancing secure communications would increase along with
interoperability.
Additionally, BEET is valuable for low-power devices, as it reduces
power consumption and complexity. In situations where
devices or IPsec connections are dedicated to a single application or transport
protocol. In this use case BEET mode simplifies packet processing and conserves
energy, especially for lower-powered devices.
IKEv2 Negotiation
When negotiating a Child SA using using IKEv2, the initiator may use
the new "USE_BEET_MODE" Notify Message to request a Child SA pair with
BEET mode support. The method used is similar to how USE_TRANSPORT_MODE
is negotiated, as described in
To request a BEET-mode SA on the Child SA pair, the initiator MUST
include the USE_BEET_MODE Notify Message when requesting a new Child
SA, either during the IKE_AUTH or CREATE_CHILD_SA exchanges.
If the request is accepted, the response MUST also include a USE_BEET_MODE
Notification. If the responder declines and does not include the
USE_BEET_MODE notification in the response, the child SA may be
established without BEET mode enabled. If this is unacceptable to the
initiator, the initiator MUST delete the child SA.
Payload Length - MUST be 0.
Protocol ID (1 octet) - MUST be 0. MUST be ignored if not 0.
SPI Size (1 octet) - MUST be 0. MUST be ignored if not 0.
As the use of the USE_BEET_MODE mode payload is currently only defined
for non-transport-mode tunnels, the USE_BEET_MODE notification MUST NOT
be combined with the USE_TRANSPORT notification.
This document defines a new IKEv2 Notify Message Type payloads for the IANA "IKEv2 Notify Message Types - Status Types" registry.
Security Considerations In this section we discuss the security properties of the BEET mode,
discussing some and point out some of its limitations .
There are no known new vulnerabilities that the addition of the
BEET mode to IKEv2 would create.
Since the BEET security associations have the semantics of a fixed,
point-to-point tunnel between two IP addresses, it is possible to
place one or both of the tunnel end points into other nodes but those
that actually "possess" the inner IP addresses, i.e., to implement a
BEET mode proxy. However, since such usage defeats the security
benefits of combined ESP processing, as discussed in ,
the implementations SHOULD NOT support such usage. Implementation Status
[Note to RFC Editor: Please remove this section and the reference to
before publication.]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of
this Internet-Draft, and is based on a proposal described in
. The description of implementations in this
section is intended to assist the IETF in its decision processes
in progressing drafts to RFCs. Please note that the listing of
any individual implementation here does not imply endorsement
by the IETF. Furthermore, no effort has been spent to verify the
information presented here that was supplied by IETF contributors.
This is not intended as, and must not be construed to be, a catalog
of available implementations or their features. Readers are advised
to note that other implementations may exist.
According to , "this will allow reviewers
and working groups to assign due consideration to documents that
have the benefit of running code, which may serve as evidence of
valuable experimentation and feedback that have made the implemented
protocols more mature. It is up to the individual working groups
to use this information as they see fit".
Authors are requested to add a note to the RFC Editor at the
top of this section, advising the Editor to remove the entire
section before publication, as well as the reference to .
Linux
Organization:
Linux kernel Project
Name:
Linux Kernel https://www.kernel.org/
Description:
Implements BEET mode in ESP. The initial support was added in 2006. It is widely used
Level of maturity:
Stable and used for over 15 years
Licensing:
GPLv2
Implementation experience:
There is no support for IPv4 fragments yet. IPv6 fragments
appears to work. The BEE mode code is in production for over a decade
Implements BEET mode support in ESP. e.g. command support "ip xfrm policy ... mode beet" . and "ip xfrm state .. mode beet". The initial support was added in 2006
Level of maturity:
Stable
Licensing:
GPLv2
Implementation experience:
TBD
Contact:
https://lore.kernel.org/netdev/ or Stephen Hemminger stephen@networkplumber.org
Acknowledgments
We extend our sincere gratitude to the authors and contributors who
contributed to the standardization of BEET mode. Their insights and dedication
have significantly influenced our work, as well as their contributions to the
implementation of BEET mode many years ago.
Normative ReferencesInformative ReferencesAdditional StuffThis becomes an Appendix.