< draft-smyslov-ipsecme-ikev2-fragmentation-00.txt   draft-smyslov-ipsecme-ikev2-fragmentation-01.txt >
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Intended status: Informational October 15, 2012 Intended status: Informational April 10, 2013
Expires: April 18, 2013 Expires: October 12, 2013
IKEv2 Fragmentation IKEv2 Fragmentation
draft-smyslov-ipsecme-ikev2-fragmentation-00 draft-smyslov-ipsecme-ikev2-fragmentation-01
Abstract Abstract
This document describes the way to avoid IP fragmentation of large This document describes the way to avoid IP fragmentation of large
IKEv2 messages. This allows IKEv2 messages to traverse network IKEv2 messages. This allows IKEv2 messages to traverse network
devices that don't allow IP fragments to pass through. devices that don't allow IP fragments to pass through.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2013. This Internet-Draft will expire on October 12, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Protocol details . . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol details . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Activation . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Using IKE Fragmentation . . . . . . . . . . . . . . . . . 5
2.5. Fragmenting Message . . . . . . . . . . . . . . . . . . . 6 2.5. Fragmenting Message . . . . . . . . . . . . . . . . . . . 6
2.5.1. Fragment size . . . . . . . . . . . . . . . . . . . . 7 2.5.1. Selecting Fragment Size . . . . . . . . . . . . . . . 7
2.5.2. Fragmenting Messages containing unencrypted 2.5.2. Fragmenting Messages containing unencrypted
Payloads . . . . . . . . . . . . . . . . . . . . . . . 8 Payloads . . . . . . . . . . . . . . . . . . . . . . . 8
2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 9 2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 9
2.6.1. Replay Protection . . . . . . . . . . . . . . . . . . 9 2.6.1. Changes in Replay Protection Logic . . . . . . . . . . 10
3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 3. Interaction with other IKE extensions . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Informative References . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The Internet Key Exchange Protocol version 2 (IKEv2), specified in The Internet Key Exchange Protocol version 2 (IKEv2), specified in
[RFC5996], uses UDP as a transport for its messages. When IKE [RFC5996], uses UDP as a transport for its messages. When IKE
message size exceed path MTU, it gets fragmented by IP level. The message size exceed path MTU, it gets fragmented by IP level. The
problem is that some network devices, specifically some NAT boxes, problem is that some network devices, specifically some NAT boxes,
don't allow IP fragments to pass through. This apparently blocks IKE don't allow IP fragments to pass through. This apparently blocks IKE
communication and, therefore, prevents peers from establishing IPsec communication and, therefore, prevents peers from establishing IPsec
SA. SA.
The solution to the problem described in this document is to perform The solution to the problem described in this document is to perform
fragmentation of large messages by IKE itself, replacing them by fragmentation of large messages by IKE itself, replacing them by
series of smaller messages. In this case the resulting IP datagrams series of smaller messages. In this case the resulting IP Datagrams
will be small enough so that no fragmentation on IP level will take will be small enough so that no fragmentation on IP level will take
place. place.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Protocol details 2. Protocol details
2.1. Overview 2.1. Overview
The idea of the protocol is to split large IKE message into the set The idea of the protocol is to split large IKE message into the set
of smaller ones, calling Fragment Messages. On the receiving side of smaller ones, calling Fragment Messages. On the receiving side
Fragment Messages are collected and merged together to get original Fragment Messages are collected and merged together to get original
message. In general this approach increases receiver's vulnerability message. In general this approach increases receiver's vulnerability
to Denial of Service attack. To reduce this vulnerability Fragment to Denial of Service attack. To reduce this vulnerability Fragment
Messages are individually encrypted and authenticated. This implies Messages are individually encrypted and authenticated. This implies
that message cannot be fragmented until shared secret is calculated. that message cannot be fragmented until shared secret is calculated.
This take place once IKE_SA_INIT exchange has completed.
2.2. Limitations 2.2. Limitations
In general, original message can be fragmented if and only if it In general, original message can be fragmented if and only if it
contains Encrypted Payload. That said, messages in IKE_SA_INIT contains Encrypted Payload. It means that messages in IKE_SA_INIT
Exchange cannot be fragmented. In most cases this is not a problem, Exchange cannot be fragmented. In most cases this is not a problem,
since IKE_SA_INIT messages are usually small enough to avoid IP since IKE_SA_INIT messages are usually small enough to avoid IP
fragmentations. But in some cases (advertising a badly structured fragmentation. But in some cases (advertising a badly structured
long list of algorithms, using large MODP Groups, etc.) those long list of algorithms, using large MODP Groups, etc.) those
messages may become fairly large and get fragmented by IP level. In messages may become fairly large and get fragmented by IP level. In
these cases the described solution won't help. these cases the described solution won't help.
Another limitation is that the minimal size of IP datagram bearing Another limitation is that the minimal size of IP Datagram bearing
IKE Fragment Message is about 100 bytes depending on the algorithms IKE Fragment Message is about 100 bytes depending on the algorithms
employed. According to [RFC0791] the minimum IP datagram size that employed. According to [RFC0791] the minimum IP Datagram size that
is guaranteed not to be further fragmented is 68 bytes. So, even the is guaranteed not to be further fragmented is 68 bytes. So, even the
smallest IKE Fragment Messages could be fragmented by IP level in smallest IKE Fragment Messages could be fragmented by IP level in
some circumstances. But such extremely small PMTU sizes are very some circumstances. But such extremely small PMTU sizes are very
rare in real life. rare in real life.
2.3. Negotiation 2.3. Negotiation
Initiator MAY indicate its support for IKE Fragmentation and Initiator MAY indicate its support for IKE Fragmentation and
willingness to use it by including Notification Payload of type willingness to use it by including Notification Payload of type
IKE_FRAGMENTATION_SUPPORTED in IKE_SA_INIT request message. If IKE_FRAGMENTATION_SUPPORTED in IKE_SA_INIT request message. If
skipping to change at page 5, line 24 skipping to change at page 5, line 22
o Protocol ID (1 octet) MUST be 0. o Protocol ID (1 octet) MUST be 0.
o SPI Size (1 octet) MUST be 0, meaning no SPI is present. o SPI Size (1 octet) MUST be 0, meaning no SPI is present.
o Notify Message Type (2 octets) - MUST be xxxxx, the value assigned o Notify Message Type (2 octets) - MUST be xxxxx, the value assigned
for IKE_FRAGMENTATION_SUPPORTED by IANA. for IKE_FRAGMENTATION_SUPPORTED by IANA.
This Notification contains no data. This Notification contains no data.
2.4. Activation 2.4. Using IKE Fragmentation
Once support for IKE Fragmentation is negotiated, any peer MAY After IKE Fragmentation is negotiated, it is up to Initiator of each
activate it. Activation is performed simply by sending IKE Fragment Exchange, whether to use it or not. In most cases IKE Fragmentation
Messages instead of original IKE Message. Until any IKE Fragment will be used in IKE_AUTH Exchange, especially if certificates are
Message appeared on the wire, IKE Fragmentation is considered employed. Initiator may first try to send unfragmented message and
inactive and behavior of the peers is identical to described in resend it fragmented only if it didn't receive response after several
[RFC5996]. retransmissions, or it may always send messages fragmented (but see
Section 3), or it may fragment only large messages and messages
causing large responses.
Activation MUST be done by Initiator of Exchange. This is not In general the following guidelines are applicable:
necessary to be Original Initiator of the IKE SA. There my be two
reasons to activate IKE Fragmentation:
o Initiator didn't receive response message after sending o Initiator MAY fragment outgoing message if it suspects that either
retransmissions several times. In this case Initiator may suspect request or response message may be fragmented by IP level.
that either request or response message get fragmented by IP level
and some of those fragments get lost. In this case it MAY try to
use IKE Fragmentation on further retransmissions.
o Initiator knows beforehand (probably by some administrative means) o Initiator SHOULD fragment outgoing message if it suspects that
that IKE Fragmentation is necessary to communicate with particular either request or response message may be fragmented by IP level
peer. In this case there is no additional delay in completing and IKE Fragmentation was already used in one of previous
Exchange if IP fragments are dropped, but some constant overhead Exchanges in the context of the current IKE SA.
is present even if no IP fragmentation takes place or IP fragments
successfully pass through.
Activation may be done in any Exchange. In most cases it will be o Initiator SHOULD NOT fragment outgoing message if both request and
IKE_AUTH Exchange, because its messages may be fairly large due to response messages of the Exchange are small enough not to cause
certificates inclusion. Once activated IKE Fragmentation cannot de fragmentation on IP level (for example, there is no point in
deactivated until IKE SA dies. fragmenting Liveness Check messages).
2.5. Fragmenting Message Responder MUST send response message in the same form (fragmented or
not) as corresponded request message. If it received unfragmented
request message, responded with unfragmented response message and
then received fragmented retransmission of the same request, it MUST
resend its response back to Initiator fragmented.
Sender decides to fragment outgoing message if IKE fragmentation is 2.5. Fragmenting Message
active and message size exceeds some fragmentation threshold. In
some cases message may be sent as IKE Fragment Message even if its
size less than threshold. In particular, this may be necessary when
activating IKE Fragmentation. In this case it is possible that
request message reaches responder, but response message got
fragmented and doesn't reach initiator. In this case initiator need
to send IKE Fragment Message to activate IKE Fragmentation even if
original message size doesn't exceed fragmentation threshold.
Message to be fragmented MUST contain Encrypted Payload. For the Message to be fragmented MUST contain Encrypted Payload. For the
purpose of IKE Fragment Messages construction original (unencrypted) purpose of IKE Fragment Messages construction original (unencrypted)
content of Encrypted Payload is broken down into parts. It is content of Encrypted Payload is broken down into parts. Its content
treated as a binary blob and is broken down regardless of inner is treated as a binary blob and is broken down regardless of inner
Payloads boundaries. Each of resulting parts is treated as a content Payloads boundaries. Each of resulting parts is treated as a content
for Encrypted Fragment Payload. for Encrypted Fragment Payload.
The Encrypted Fragment Payload, denoted SKF{...}, contains other The Encrypted Fragment Payload, denoted SKF{...}, contains other
payloads in encrypted form. The Encrypted Fragment Payload, as well payloads in encrypted form. The Encrypted Fragment Payload, as well
as Encrypted Payload from [RFC5996], if present in a message, MUST be as Encrypted Payload from [RFC5996], if present in a message, MUST be
the last payload in the message. the last payload in the message.
The payload type for an Encrypted Fragment payload is XXX (TBA by The payload type for an Encrypted Fragment payload is XXX (TBA by
IANA). IANA).
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Number | Total Fragments | | Fragment Number | Total Fragments |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector | | Initialization Vector |
| (length is block size for encryption algorithm) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Encrypted content ~ ~ Encrypted content ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) | | | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | Pad Length | | | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Checksum Data ~ ~ Integrity Checksum Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encrypted Fragment Payload Encrypted Fragment Payload
o Next Fragment (1 octet) - in the very first fragment MUST be set o Next Fragment (1 octet) - in the very first fragment MUST be set
to Payload Type of the first inner Payload (as in Encrypted to Payload Type of the first inner Payload (as in Encrypted
Payload). In the rest fragments MUST be set to zero. Payload). In the rest fragments MUST be set to zero.
o Fragment Number (2 octets) - current fragment number starting from o Fragment Number (2 octets) - current fragment number starting from
1. 1. This field MUST be less than or equal to the next field, Total
Fragments.
o Total Fragments (2 octets) - number of fragments original message o Total Fragments (2 octets) - number of fragments original message
was divided into. was divided into. This field MUST NOT be zero.
Other fields are identical to those specified in Section 3.14 of Other fields are identical to those specified in Section 3.14 of
[RFC5996]. [RFC5996].
When prepending IKE Header, Length field MUST be adjusted to reflect When prepending IKE Header, Length field MUST be adjusted to reflect
the length of constructed message and Next Payload field MUST reflect the length of constructed message and Next Payload field MUST reflect
payload type of the first Payload in the constructed message (that in payload type of the first Payload in the constructed message (that in
most cases will be Encrypted Fragment Payload). All newly most cases will be Encrypted Fragment Payload). All newly
constructed messages MUST retain the same Message ID as original constructed messages MUST retain the same Message ID as original
message. After prepending IKE Header and possibly any of Payloads message. After prepending IKE Header and possibly any of Payloads
that precedes Encrypted Payload in original message (see that precedes Encrypted Payload in original message (see
Section 2.5.2), the resulting messages are sent to the peer. Section 2.5.2), the resulting messages are sent to the peer.
Below is an example of fragmenting Message. Below is an example of fragmenting some message.
HDR(MID=n), SK(NextPld=PLD1) {PLD1 ... PLDN} HDR(MID=n), SK(NextPld=PLD1) {PLD1 ... PLDN}
Original Message Original Message
HDR(MID=n), SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...}, HDR(MID=n), SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...},
HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...}, HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...},
... ...
HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...} HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...}
IKE Fragment Messages IKE Fragment Messages
2.5.1. Fragment size 2.5.1. Selecting Fragment Size
When breaking content of Encrypted Payload down into parts sender When breaking content of Encrypted Payload down into parts sender
SHOULD chose size of those parts so, that resulting message sizes not SHOULD chose size of those parts so, that resulting IP Datagram size
exceed fragmentation threshold - be small enough to avoid IP not exceed some fragmentation threshold - be small enough to avoid IP
fragmentation. fragmentation.
If sender has some knowledge about PMTU size it MAY use it. If sender has some knowledge about PMTU size it MAY use it. If
sender is a Responder in the Exchange and it has received fragmented
request, it MAY use maximum size of received IKE Fragment Message IP
Datagrams as threshold when constructing fragmented response.
Otherwise for messages to be sent over IPv6 it is RECOMMENDED to use Otherwise for messages to be sent over IPv6 it is RECOMMENDED to use
value 1280 bytes as a maximum message size ([RFC2460]). For messages value 1280 bytes as a maximum IP Datagram size ([RFC2460]). For
to be sent over IPv4 it is RECOMENDED to use value 576 bytes as a messages to be sent over IPv4 it is RECOMMENDED to use value 576
maximum message size. bytes as a maximum IP Datagram size.
According to [RFC0791] the minimum IP datagram size that is For IPv4 Encrypted Payload content size is less than IP Datagram size
by the sum of the following values:
o IPv4 header size (typically 20 bytes, up to 60 if IP options are
present)
o UDP header size (8 bytes)
o non-ESP marker size (4 bytes if present)
o IKE Header size (28 bytes)
o Encrypted Payload header size (4 bytes)
o IV size (varying)
o padding and its size (at least 1 byte)
o ICV size (varying)
The sum may be estimated as 61..105 bytes + IV + ICV + padding. For
IPv6 this estimation is difficult as there may be varying IPv6
Extension headers included.
According to [RFC0791] the minimum IPv4 datagram size that is
guaranteed not to be further fragmented is 68 bytes, but it is guaranteed not to be further fragmented is 68 bytes, but it is
generally impossible to use such small value for solution, described generally impossible to use such small value for solution, described
in this document. Using 576 bytes is a compromise - the value is in this document. Using 576 bytes is a compromise - the value is
large enough for the presented solution and small enough to avoid IP large enough for the presented solution and small enough to avoid IP
fragmentation in most situations. Sender MAY use other values if it fragmentation in most situations. Sender MAY use other values if
is appropriate. they are appropriate.
Initiator MAY try to discover path MTU by using several values of
fragmentation threshold, provided that it starts with larger values
and fragments message again with next smaller value if it doesn't
receive response in a reasonable time after several retransmissions.
In this case using next smaller value MUST result in increasing Total
Fragments field.
2.5.2. Fragmenting Messages containing unencrypted Payloads 2.5.2. Fragmenting Messages containing unencrypted Payloads
Currently no one of IKEv2 Exchanges defines messages, containing both Currently no one of IKEv2 Exchanges defines messages, containing both
unencrypted payloads and payloads, protected by Encrypted Payload. unencrypted payloads and payloads, protected by Encrypted Payload.
But IKEv2 doesn't forbid such messages. So, if some future IKEv2 But IKEv2 doesn't forbid such messages. If some future IKEv2
extension defines such a message and it needs to be fragmented, all extension defines such a message and it needs to be fragmented, all
unprotected payloads (if any) MUST be in the first fragment, along unprotected payloads MUST be in the first fragment, along with
with Encrypted Fragment Payload, which MUST be present in any IKE Encrypted Fragment Payload, which MUST be present in any IKE Fragment
Fragment Message. Message.
Below is an example of fragmenting Message, containing both encrypted Below is an example of fragmenting message, containing both encrypted
and unencrypted Payloads. and unencrypted Payloads.
HDR(MID=n), PLD0, SK(NextPld=PLD1) {PLD1 ... PLDN} HDR(MID=n), PLD0, SK(NextPld=PLD1) {PLD1 ... PLDN}
Original Message Original Message
HDR(MID=n), PLD0, SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...}, HDR(MID=n), PLD0, SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...},
HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...}, HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...},
... ...
HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...} HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...}
IKE Fragment Messages IKE Fragment Messages
Note, that size each of IKE Fragment Messages SHOULD not exceed Note, that the size of each IP Datagram bearing IKE Fragment Messages
fragmentation threshold, including the very first, which contains SHOULD not exceed fragmentation threshold, including the very first,
unprotected Payloads. This will reduce size of Encrypted Fragment which contains unprotected Payloads. This will reduce the size of
Payload content in the first IKE Fragment Message to accommodate Encrypted Fragment Payload content in the first IKE Fragment Message
unprotected Payloads. In extreme cases Encrypted Fragment Payload to accommodate unprotected Payloads. In extreme cases Encrypted
will contain no data, but it is still MUST be present in the message, Fragment Payload will contain no data, but it is still MUST be
because only its presence allows receiver to distinguish IKE Fragment present in the message, because only its presence allows receiver to
Message from IKE Message. distinguish IKE Fragment Message from regular IKE message.
2.6. Receiving IKE Fragment Message 2.6. Receiving IKE Fragment Message
Receiver identifies IKE Fragment Message by the presence of Encrypted Receiver identifies IKE Fragment Message by the presence of Encrypted
Fragment Payload in it. Note, that it is possible for this payload Fragment Payload in it. Note, that it is possible for this payload
to be not the first payload in message (see Section 2.5.2). But for to be not the first (and the only) payload in the message (see
all currently defined IKEv2 exchanges this payload will be the first Section 2.5.2). But for all currently defined IKEv2 exchanges this
and the only payload in the message. payload will be the first and the only payload in the message.
Upon receiving IKE Fragment Message the following actions are Upon receiving IKE Fragment Message the following actions are
performed: performed:
o check message validity - in particular, check whether values of o Check message validity - in particular, check whether values of
Fragment Number and Total Fragments in Encrypted Fragment Payload Fragment Number and Total Fragments in Encrypted Fragment Payload
make sense. If not - message MUST be silently discarded. are valid. If not - message MUST be silently discarded.
o check, that this IKE Fragment Message is new for the receiver and o Check, that this IKE Fragment Message is new for the receiver and
not replay. If message with the same Message ID and same Fragment not a replay. If IKE Fragment message with the same Message ID,
Number in Encrypted Fragment Payload was already received and same Fragment Number and same Total Fragments fields was already
processed, this message MUST be silently discarded. received and successfully processed, this message is considered a
replay and MUST be discarded.
o verify IKE Fragment Message authenticity by checking ICV in o Verify IKE Fragment Message authenticity by checking ICV in
Encrypted Fragment Payload. If ICV check fails message MUST be Encrypted Fragment Payload. If ICV check fails message MUST be
silently discarded. silently discarded.
o store message in the list waiting for the rest of fragments to o If reassembling isn't finished yet and Total Fragments field in
received IKE Fragment Message is greater than this field in
previously received fragments, receiver MUST discard all received
fragments and start reassembling over with just received IKE
Fragment Message.
o Store message in the list waiting for the rest of fragments to
arrive. arrive.
When all IKE Fragment Messages (as indicated in the field Total When all IKE Fragment Messages (as indicated in the Total Fragments
Fragments) are received, content of their Encrypted Fragment Payloads field) are received, content of their Encrypted Fragment Payloads is
is decrypted and merged together to form original message, which is decrypted and merged together to form content of original Encrypted
then processed as regular unfragmented message. Payload, and, therefore, along with IKE Header, original message.
Then it is processed as if it was received, verified and decrypted as
as regular unfragmented message.
2.6.1. Replay Protection 2.6.1. Changes in Replay Protection Logic
According to [RFC5996] IKEv2 MUST reject message with the same According to [RFC5996] IKEv2 MUST reject message with the same
Message ID as it has seen before (taking into consideration Response Message ID as it has seen before (taking into consideration Response
bit). This logic has already been updated by [RFC6311], which bit). This logic has already been updated by [RFC6311], which
deliberately allows any number of Messages with Message ID zero. deliberately allows any number of messages with zero Message ID.
This document also updates this logic: if message contains Encrypted This document also updates this logic: if message contains Encrypted
Fragment Payload, the value of Fragment Number field from this Fragment Payload, the values of Fragment Number and Total Fragments
payload MUST be used along with Message ID to detect retransmissions fields from this payload MUST be used along with Message ID to detect
and replays. In other words, to consider message as replay or retransmissions and replays.
retransmission 2-tuple of Message ID and Fragment Number must be met
before in context of this particular SA.
3. Security Considerations If Responder receives IKE Fragment Message after it received,
successfully verified and processed regular message with the same
Message ID, it means that response message didn't reach Initiator and
it activated IKE Fragmentation. If Fragment Number in Encrypted
Fragment Payload in this message is equal to 1, Responder MUST
fragment its response and retransmit it back to Initiator in
fragmented form.
If Responder receives a replay IKE Fragment Message for already
reassembled, verified and processed fragmented message, it MUST
retransmit response back to Initiator, but only if Fragment Number
field in Encrypted Fragment Payload is equal to 1 and MUST silently
discard received message otherwise.
3. Interaction with other IKE extensions
IKE Fragmentation is compatible with most of defined IKE extensions,
like IKE Session Resumption [RFC5723], Quick Crash Detection Method
[RFC6290] and so on. It neither affect their operation, nor is
affected by them. It is believed that IKE Fragmentation will also be
compatible with most future IKE extensions, if they follow general
principles of formatting, sending and receiving IKE messages,
described in [RFC5996].
The notable exception that requires a special care is [RFC6311] -
Protocol Support for High Availability of IKEv2. As it deliberately
allows any number of synchronization Exchanges to have the same
Message ID - zero, standard replay detection logic, based on checking
Message ID is not applicable for such messages, and receiver has to
check message content to detect replays. When implementing IKE
Fragmentation along with [RFC6311], IKE Message ID Synchronization
messages MUST NOT be sent fragmented to simplify receiver's task of
detecting replays. Fortunately, these messages are small and there
is no point in fragmenting them anyway.
4. Security Considerations
Most of the security considerations for IKE Fragmentation are the Most of the security considerations for IKE Fragmentation are the
same as those for base IKEv2 protocol described in [RFC5996]. This same as those for base IKEv2 protocol described in [RFC5996]. This
extension introduces Encrypted Fragment Payload to protect content of extension introduces Encrypted Fragment Payload to protect content of
IKE Message Fragment. This allows receiver to individually check IKE Message Fragment. This allows receiver to individually check
authenticity of fragments, thus protecting itself from Denial of authenticity of fragments, thus protecting itself from Denial of
Service attack. Service attack.
4. IANA Considerations 5. IANA Considerations
This document defines new Payload in the "IKEv2 Payload Types" This document defines new Payload in the "IKEv2 Payload Types"
registry: registry:
<TBA> Encrypted Fragment Payload SKF <TBA> Encrypted Fragment Payload SKF
This document also defines new Notify Message Types in the "Notify This document also defines new Notify Message Types in the "Notify
Messages Types - Status Types" registry: Messages Types - Status Types" registry:
<TBA> IKE_FRAGMENTATION_SUPPORTED <TBA> IKE_FRAGMENTATION_SUPPORTED
5. References 6. References
5.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", "Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010. RFC 5996, September 2010.
5.2. Informative References [RFC6311] Singh, R., Kalyani, G., Nir, Y., Sheffer, Y., and D.
Zhang, "Protocol Support for High Availability of IKEv2/
IPsec", RFC 6311, July 2011.
6.2. Informative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC6311] Singh, R., Kalyani, G., Nir, Y., Sheffer, Y., and D. [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
Zhang, "Protocol Support for High Availability of IKEv2/ Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
IPsec", RFC 6311, July 2011. January 2010.
[RFC6290] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A
Quick Crash Detection Method for the Internet Key Exchange
Protocol (IKE)", RFC 6290, June 2011.
Author's Address Author's Address
Valery Smyslov Valery Smyslov
ELVIS-PLUS ELVIS-PLUS
PO Box 81 PO Box 81
Moscow (Zelenograd) 124460 Moscow (Zelenograd) 124460
RU RU
Phone: +7 495 276 0211 Phone: +7 495 276 0211
 End of changes. 54 change blocks. 
115 lines changed or deleted 191 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/