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 inner flow information to the network in a transparent
way. To do so, it adapts IPv6 Extension header options to WESPv2
where flow identitiers 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
.
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 WESPv2 Options introduced by WESPv2 are considered to
be opaque to this document. Future documents can define the meaning of
these fields for their particular use-case. With this, all existing and
potential new use-cases for Flow Identifiers can be covered. For
instance it can be used for the case of
or
etc., or combinations
thereof. 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 defines Options to store a integrity protected flow
identifiers that can be used for flow classification.The header is constructed in a way that the start of the following next header
is aligned on a 4 byte boundary on IPv4 and on a 8 byte boundary on IPv6
respective the start of the IPv4/IPv6 header. 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. When the Crypt Offset field is zero, the Next Header MUST be
set to 59, Section 4.7. 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 59 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 Options can carry enough information about inner
flows, we can remove the cryptoffset.)
Reserved - 2 bits: Set to zero on transmit, ignored on
receive.
Version (V) - 2 bits: MUST be sent to 01 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).
OptLen - 6 bit: Total length of all options included in the WESPv2
header Options, in octets.
Options - variable: Authenticated field with
additional flow informations and padding.
OptionsWESPv2 options carry a variable number of "options" that are
type-length- value (TLV) encoded in the same format as done in
Section 4.2 for IPv6 extension headers.
This document defines three different option classes, Padding Options,
Flow Identifier Options and Private Options.Padding Options MUST be used to align the start of the next
header to the natural alignment of the protocol, i.e. 4 byte for IPv4
and 8 byte for IPv6. Other padding, like padding for cipher text alignment,
is out of the scope of this document. Future documents can define this
by using the existing padding options. Additional padding MUST be
negotiated by IKEv2 or any other suitable protocol.
Flow Identifier Options MUST carry characteristic information of the inner flow, i.e.
MUST NOT change on per packet basis. It MUST be negotiated by
IKEv2 or any other suitable protocol.
The detailed specification of
Flow Identifiers MUST be provided in subsequent documents. These Options are
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. Flow Identifiers MUST have the format of Options
as defind in .
Private Options comming from a reserved Option Type Range and
can be used for any purposes that are out of scope for standardization.
For example it can be used to encode hardware specific information,
such as used encryption/authentication algorithms as done in .The only WESPv2 Option Types defined in this document are the Pad1 and
PadN options specified in .WESPv2 extension header Options are adapted from IPv6 extension header Options as
defined in Section 4.2 of , with the following modifications:
References to the IPv6 header are removed.
The two highest-order bits of the Option Type MUST be set to 00, if the Option
Type comes from the private range.
The third-highest-order bit of the Option Type MUST be set to 0.
References to the Hop-by-Hop
Options header and the Destination Options header are removed.
WESPv2 Options
carry a variable number of type-length-value (TLV) encoded
"options", of the following format:
Option Type: 8-bit identifier of the type of option.
Opt Data Len: 8-bit unsigned integer. Length of
the Option Data field of this option, in octets.
The sequence of options within a header must be processed
strictly in the order they appear in the header; a receiver must
not, for example, scan through the header looking for a particular
kind of option and process that option prior to processing all
preceding ones.The Option Type identifiers are internally encoded such that
their highest-order two bits specify the action that must be taken
if the processing node does not recognize the Option Type:
00 - skip over this option and continue processing
the header.
01 - discard the packet.
10 - discard the packet and, regardless of whether
or not the packet's Destination Address was a multicast address,
send an ICMP Parameter Problem, Code 2, message to the packet's
Source Address, pointing to the unrecognized Option Type.
11 - discard the packet and, only if the packet's
Destination Address was not a multicast address, send an ICMP
Parameter Problem, Code 2, message to the packet's Source
Address, pointing to the unrecognized Option Type.
Options from the private range MUST set the two
highest-order bit to 00.The third-highest-order bit of the Option Type specifies
whether or not the Option Data of that option can change en-route
to the packet's final destination. That bit is left in to be
compliant with IPv6 extenstion header options. WESPv2
options are authenticated, therefore this bit MUST be set to 0.
0 - Option Data does not change en-route
1 - Option Data may change en-route
The three high-order bits described above are to be treated as
part of the Option Type, not independent of the Option Type. That
is, a particular option is identified by a full 8-bit Option Type,
not just the low-order 5 bits of an Option Type.Individual options may have specific alignment requirements, to
ensure that multi-octet values within Option Data fields fall on
natural boundaries. The alignment requirement of an option is
specified using the notation xn+y, meaning the Option Type must
appear at an integer multiple of x octets from the start of the
header, plus y octets. For example:
2n means any 2-octet offset from the start of the header.
8n+2 means any 8-octet offset from the start of the header,
plus 2 octets.
There are two padding options which are used when necessary to
align subsequent options and to pad out the containing header to a
multiple of 8 octets in length. These padding options must be
recognized by all implementations:Pad1 option (alignment requirement: none)Note! the format of the Pad1 option is a special case -- it
does not have length and value fields.
The Pad1 option is used to insert one octet of padding into the
Options area of a header. If more than one octet of padding is
required, the PadN option, described next, should be used, rather
than multiple Pad1 options.PadN option (alignment requirement: none)The PadN option is used to insert two or more octets of padding
into the Options area of a header. For N octets of padding, the
Opt Data Len field contains the value N-2, and the Option Data
consists of N-2 zero-valued octets.Appendix A of contains applicable formatting guidelines for
designing new options.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 all header Options 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 | OPT | ESP | Pyld | ESP |ESP|
|(any options)| BHdr | (var) | Hdr | Data |Trailer|ICV|
-------------------------------------------------------
|<-encryption->|
|<----------- integrity ----------->|
]]>
IPv6 DatagramIPv6 DATAGRAM BEFORE APPLYING WESPIPv6 DATAGRAM AFTER APPLYING WESP
|
-------------------------------------------------------
| outer |ext.| WESP | OPT | ESP | Pyld | ESP |ESP|
|IPv6 Hdr|Hdrs| BHdr | (var) | 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.This document requests IANA to create a registry called
"WESP_OPTIONS Type Registry" under a new category named
"WESP_OPTIONS Parameters". This initial content for this registry is as follows: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