Wrapped ESP Version 2secunet Security Networks AGsteffen.klassert@secunet.comsecunet Security Networks AGantony.antony@secunet.com
sec
IPSECME Working GroupIKEv2WESPv2This document describes the Wrapped Encapsulating Security Payload v2
(WESPv2) protocol, which builds on the Encapsulating Security Payload
(ESP)
. It is designed to overcome limitations of the
ESP protocol to expose flow information to the network in a transparent
way and to align the cipher text to the needs of the sender and receiver.
To do so, it defines an optional Flow Identifier where flow specific
information can be stored. It also defines a Crypt Offset to allow
intermediate devices to read some header bytes at the beginning of the
inner packet. In particular, this preserves the original use-case of WESP
. Optional padding can be added for cipher text
alignment.IntroductionWESPv2 is a wrapper for the ESP protocol. Due to the absence of a
version number in the ESP protocol, in the packet header, ESP can't be
updated in a transparent way. Any updates to ESP must be negotiated by
IKEv2 and for that, indiscernible to intermediate devices such as routers
and firewalls. In the recent past, several attempts were taken to
introduce a Flow Identifier for certain use-cases. Examples are
and
. Such a Flow
Identifier could also be used to perform ECMP based on the inner flows at
intermediate devices or endpoints. Additionally to that, there exists a
specification of the
protocol that has the need of a Flow Identifier,
called
Network Identifier (VNI) there. PSP also defines a Crypto Offset to expose
parts of the headers of the inner packet. Showing headers on the inner
packet was also the original usecase for the WESP protocol. WESPv2
provides a solution for all the aforementioned use-cases.The 64 bit Flow Identifier field introduced by WESPv2 is considered to
be opaque to this document. Future documents can define the meaning of
this field for their particular use-case. With this, all existing and
potential new use-cases for a Flow Identifier can be covered. For
instance it can be used for the case of
or
etc., or combinations
thereof if fit into the 64 bit field. A detailed discussion about the
problems of the ESP protocol can be found in
.Though this document specifies IKEv2 as a negotiation protocol, WESPv2
may use other protocols for negotiation and key derivation. The packet
specification is portable to other key protocol use cases, such as
, and offers versioning at the packet level.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.TerminologyThis document uses the following terms defined in IKEv2
: Child SA, CREATE_CHILD_SA, IKE_AUTH
exchange, USE_TRANSPORT_MODEThis document uses the following terms defined in
: PSP (a recursive acronym for PSP Security
Protocol), Network Identifier (VNI), Crypt Offset.This document uses the following terms defined in
: Wrapped Encapsulating Security Payload
(WESP), USE_WESP_MODE.This document uses the following terms defined in
: Equal-cost multi-path (ECMP)This document uses the following terms defined in
: Encapsulating Security Payload (ESP).This document uses the following terms defined in
:
Sub-Child SA.Protocol DefinitionIn this section we define the exact protocol formats and operations.
This section is normative.WESPv2 header formatThe WESPv2 header is split into a 4 byte base header that is always
present and an optional part directly following the base header. The
base header essentially describes how to treat the packet. The optional
part of the header ensure proper alignment of the ESP cipher text. It
also has an option to store an integrity protected flow identifier
that can be used for flow classification.The header is constructed in a way that the start of the cipher-text
is aligned on a 8 byte boundary respective the start of the IPv4/IPv6
header. Any IPv4 options and optional IPv6 extension Headers are not
taken into account here. If the sender has different alignment
requirements, optional padding can be used to align the cipher-text.
The chosen padding size SHOULD NOT change for a given Child SA.
(Authors note: Should the padding size be negotiated?) Like WESPv1,
this extension essentially acts as a wrapper to the existing ESP
protocol. The value of the new protocol version used to identify this
new header is not changed. Instead, the version number in the Flags
field is incremented to identify this new protocol version. Further
details are shown below:WESPv2 header format
Next Header - 8 bits: This field MUST be the same as the Next
Header field in the ESP trailer whenever the Crypt Offset field is
nonzero. If the Crypt Offset field is zero, the Next Header MUST be
set to zero too. The receiver MUST do some sanity checks before the
WESPv2 packet is accepted. The receiver MUST ensure that the Next
Header field in the WESPv2 header and the Next Header field in the
ESP trailer match whenever the Next Header field is nonzero. The
packet MUST be dropped if the two do not match. Similarly, the
receiver MUST ensure that the Next Header field in the WESPv2 header
is an empty field initialized to zero if the Crypt Offset field is
zero.
HdrLen - 8 bits: Offset from the beginning of the WESPv2 header
to the beginning of the Rest of Payload Data (i.e., past the IV, if
present and any other WESPv2 options defined in the future) within
the encapsulated ESP header, in octet. The following HdrLen values
are invalid: any value less than 12; any value that is not a multiple
of 4; any value that is not a multiple of 8 when using IPv6. The
receiver MUST ensure that this field matches with the header offset
computed from using the negotiated Security Association (SA) and MUST
drop the packet in case it does not match.
Crypt Offset - 6 bits: The offset from the end of the IV to the
start of the encrypted portion of the packet, measured in 4 octet
units. The resulting value MUST NOT be larger than the size of the
inner packet. A zero CryptOffset means that the complete packet is
authenticated and encrypted. A positive CryptOffset means that the
first 'CryptOffset * 4' octets of the inner packet belong to the AAD
but are not encrypted. In this case the Next Header field MUST be the
same as the Next Header field in the ESP trailer, so that the Header
can be parsed by intermediate devices. (Authors note: This is to
preserve the original WESP use-case and because PSP uses this too. In
case the Flow Identifier can carry enough information about inner
flows, we can remove the cryptoffset.)
Reserved - 2 bits: Set to zero on transmit, ignored on
receive.
Flags - 8 bits: The bits are defined most-significant-bit (MSB)
first, so bit 0 is the most significant bit of the flags octet.
Flags Format
Version (V) - 2 bits: MUST be sent to 1 and checked by the
receiver. If the version is different than an expected version number
(e.g., negotiated via the control channel), then the packet MUST be
dropped by the receiver. Future modifications to the WESPv2 header
require a new version number. In particular, the version of WESPv2
defined in this document does not allow for any extensions. However,
old implementations will still be able to find the encapsulated
clear-text packet using the HdrLen field from the WESPv2 header, when
the 'E' bit is not set. Intermediate nodes dealing with unknown
versions are not necessarily able to parse the packet correctly.
Intermediate treatment of such packets is policy dependent (e.g., it
may dictate dropping such packets).
Encrypted Payload (E) - 1 bit: Has no meaning in WESPv2 as the
CryptOffset declares which parts of the payload is protected with
encryption. (FIXME: should it be set to 1 to align with WESPv1?)
Padding header (P) - 1 bit: If set (value 1), the padding is
present. If not set (value 0), the padding is absent.
FID (F) - 1 bit: If set (value 1), the FID is present behind the
WESPv2 trader. If not set (value 0), the FID is absent.
R - 3 bits: Reserved for future versions, MUST be set to 0, and
ignored by the receiver.
Padding - optional: Used to ensure proper alignment of the
cipher-text. Implementations can choose alignment based on their
needs. If padding is present, it SHOULD align the cipher-text by a
minimum of 16 bytes relative to the start of the IP/IPv6 header.
Flow Identifier (FID) - optional: Authenticated field with
additional flow informations. If present, this field MUST carry
characteristic information of the inner flow, i.e.
it SHOULD NOT change on per packet basis. The detailed specification of
the FID field MUST be provided in subsequent documents. This field is
opaque to intermediate devices; however, intermediate routers MAY use
it for identifying flows for ECMP or similar purposes. e.g. Sub-Child
SAs, in
could
be encoded here. If present, MUST be 8 byte.,
UDP EncapsulationUDP Encapsulation is done as in
.Packet formatThe following section defines the resulting packet format. Tunnel
and Transport Modes are handled exactly the same way as in WESP
. The WESPv2 headers are inserted between the
outer IPv4/IPv6 header and the ESP header. The WESPv2 header MUST be
inserted before the cryptographic operations. After inserting the
WESPv2 header, the crypto operations are performed. The full WESPv2
header, including optional padding and Flow Identifier (FID) MUST be
included into the integrity protected part of the packet.IPv4 DatagramIPv4 DATAGRAM BEFORE APPLYING WESPIPv4 DATAGRAM AFTER APPLYING WESP
|
-------------------------------------------------------
|outer IP hdr |WESP| PAD | FID |ESP| Pyld | ESP |ESP|
|(any options)|BHdr|(opt)|(opt)|Hdr| Data |Trailer|ICV|
-------------------------------------------------------
|<-encryption->|
|<----------- integrity ----------->|
]]>
IPv6 DatagramIPv6 DATAGRAM BEFORE APPLYING WESPIPv6 DATAGRAM AFTER APPLYING WESP
|
-------------------------------------------------------
| outer |ext.|WESP| PAD | FID |ESP| Pyld | ESP |ESP|
|IPv6 Hdr|Hdrs|BHdr|(opt)|(opt)|Hdr| Data |Trailer|ICV|
-------------------------------------------------------
|<-encryption->|
|<----------- integrity ----------->|
]]>
IKEv2 NegotiationThe IKEv2 negotiation follows exactly the way it is done in WESP
, with the difference that a new notification
USE_WESPv2_MODE is used.This document assumes that WESPv2 negotiation is performed using
IKEv2. In order to negotiate the new format of ESP encapsulation via
IKEv2
, both parties need to agree to use the new
packet format. This can be achieved using a notification method similar
to USE_TRANSPORT_MODE, defined in
.When negotiating a WESPv2 Child SA, USE_WESPv2_MODE MUST be included
in a either in an IKE_AUTH exchange or CREATE_CHILD_SA. and the rest of
SA payload necessary for a Child SA using ESP. It signals that the sender
supports the WESPv2 version defined in the current document and requests
that the Child SA use WESPv2 mode rather than ESP for the SA created. If
the request is accepted, the response MUST also include a notification of
type USE_WESP_MODE. If the responder declines the request, the Child SA
should be established using ESP, as per
. If this is unacceptable to the initiator, the
initiator MUST delete the Child SA.Note: Except when using the options to negotiate WESPv1 or WESPv2
mode, all CHILD_SAs will use standard ESP.Negotiation of WESPv2 in this manner preserves all other negotiation
parameters, including NAT-T
. NAT-T is wholly compatible with this wrapped
format and can be used as-is, without any modifications, in environments
where NAT is present and needs to be taken into account.WESPv2 version negotiation is not specified here. If the WESP version
is updated in a future specification, then that document MUST specify how
the WESP version is negotiated.All multi-octet fields representing integers are laid out in big
endian order (also known as "most significant byte first", or "network
byte order").
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.
Notify Status Message Type value (2 octets) - set to [TBD].
Notify Payload: bit 0 reserved. bit 1 Flow ID supported. Bits 2-7
Crypt Offset len in 4 octets
This document defines a new IKEv2 Notify Message Type payloads for the
IANA "IKEv2 Notify Message Types - Status Types" registry.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
.Security ConsiderationsIn this section we discuss the security properties of WESPv2: TBDAcknowledgmentsTBDNormative ReferencesInformative ReferencesPSP Architecture SpecificationGoogleAdditional StuffTBD