draft-ietf-ipsecme-ikev2-fragmentation-10.txt   rfc7383.txt 
Network Working Group V. Smyslov Internet Engineering Task Force (IETF) V. Smyslov
Internet-Draft ELVIS-PLUS Request for Comments: 7383 ELVIS-PLUS
Intended status: Standards Track June 10, 2014 Category: Standards Track November 2014
Expires: December 12, 2014 ISSN: 2070-1721
IKEv2 Fragmentation Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation
draft-ietf-ipsecme-ikev2-fragmentation-10
Abstract Abstract
This document describes the way to avoid IP fragmentation of large This document describes a way to avoid IP fragmentation of large
IKEv2 messages. This allows IKEv2 messages to traverse network Internet Key Exchange Protocol version 2 (IKEv2) messages. This
devices that do not allow IP fragments to pass through. allows IKEv2 messages to traverse network devices that do not allow
IP fragments to pass through.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on December 12, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7383.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 ....................................................2
1.1. Problem description . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Description ........................................2
1.2. Proposed solution . . . . . . . . . . . . . . . . . . . . 3 1.2. Proposed Solution ..........................................3
1.3. Conventions Used in This Document . . . . . . . . . . . . 4 1.3. Conventions Used in This Document ..........................4
2. Protocol details . . . . . . . . . . . . . . . . . . . . . . . 5 2. Protocol Details ................................................4
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Overview ...................................................4
2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Limitations ................................................4
2.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Negotiation ................................................5
2.4. Using IKE Fragmentation . . . . . . . . . . . . . . . . . 6 2.4. Using IKE Fragmentation ....................................5
2.5. Fragmenting Message . . . . . . . . . . . . . . . . . . . 7 2.5. Fragmenting Message ........................................6
2.5.1. Selecting Fragment Size . . . . . . . . . . . . . . . 9 2.5.1. Selecting Fragment Size .............................8
2.5.2. PMTU Discovery . . . . . . . . . . . . . . . . . . . . 10 2.5.2. PMTU Discovery ......................................9
2.5.3. Fragmenting Messages containing unprotected 2.5.3. Fragmenting Messages Containing Unprotected
Payloads . . . . . . . . . . . . . . . . . . . . . . . 11 Payloads ...........................................11
2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 12 2.6. Receiving IKE Fragment Message ............................11
2.6.1. Replay Detection and Retransmissions . . . . . . . . . 14 2.6.1. Replay Detection and Retransmissions ...............13
3. Interaction with other IKE extensions . . . . . . . . . . . . 15 3. Interaction with Other IKE Extensions ..........................14
4. Transport Considerations . . . . . . . . . . . . . . . . . . . 16 4. Transport Considerations .......................................14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations ........................................15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations ............................................16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7. References .....................................................16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Normative References ......................................16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 7.2. Informative References ....................................16
8.2. Informative References . . . . . . . . . . . . . . . . . . 21 Appendix A. Design Rationale ......................................19
Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 23 Appendix B. Correlation between IP Datagram Size and Encrypted
Appendix B. Correlation between IP Datagram size and Payload Content Size ..................................19
Encrypted Payload content size . . . . . . . . . . . 24 Acknowledgements ..................................................20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 Author's Address ..................................................20
1. Introduction 1. Introduction
1.1. Problem description 1.1. Problem Description
The Internet Key Exchange Protocol version 2 (IKEv2), specified in The Internet Key Exchange Protocol version 2 (IKEv2), specified in
[IKEv2], uses UDP as a transport for its messages. Most IKEv2 [RFC7296], uses UDP as a transport for its messages. Most IKEv2
messages are relatively small, usually below several hundred bytes. messages are relatively small, usually below several hundred bytes.
Noticeable exception is IKE_AUTH Exchange, which requires fairly A notable exception is the IKE_AUTH exchange, which requires fairly
large messages, up to several kBytes, especially when certificates large messages, up to several KB, especially when certificates are
are transferred. When IKE message size exceeds path MTU, it gets transferred. When the IKE message size exceeds the path MTU, it gets
fragmented by IP level. The problem is that some network devices, fragmented at the IP level. The problem is that some network
specifically some NAT boxes, do not allow IP fragments to pass devices, specifically some NAT boxes, do not allow IP fragments to
through. This apparently blocks IKE communication and, therefore, pass through. This apparently blocks IKE communication and,
prevents peers from establishing IPsec SA. Section 2 of [IKEv2] therefore, prevents peers from establishing an IPsec Security
discusses the impact of IP fragmentation on IKEv2 and acknowledges Association (SA). Section 2 of [RFC7296] discusses the impact of IP
this problem. fragmentation on IKEv2 and acknowledges this problem.
Widespread deployment of Carrier-Grade NATs (CGN) introduces new Widespread deployment of Carrier-Grade NATs (CGNs) introduces new
challenges. [RFC6888] describes requirements for CGNs. It states, challenges. [RFC6888] describes requirements for CGNs. It states
that CGNs must comply with Section 11 of [RFC4787], which requires that CGNs must comply with Section 11 of [RFC4787], which requires
NAT to support receiving IP fragments (REQ-14). In real life NATs to support receiving IP fragments (REQ-14). In real life,
fulfillment of this requirement creates an additional burden in terms fulfillment of this requirement creates an additional burden in terms
of memory, especially for high-capacity devices, used in CGNs. It of memory, especially for high-capacity devices used in CGNs. It was
was found by people deploying IKE, that more and more ISPs use found by people deploying IKE that more and more ISPs use equipment
equipment that drop IP fragments, violating this requirement. that drops IP fragments, thereby violating this requirement.
Security researchers have found and continue to find attack vectors Security researchers have found, and continue to find, attack vectors
that rely on IP fragmentation. For these reasons, and also that rely on IP fragmentation. For these reasons, and also as
articulated in [FRAGDROP], many network operators filter all IPv6 articulated in [FRAGDROP], many network operators filter all IPv6
fragments. Also, the default behavior of many currently deployed fragments. Also, the default behavior of many currently deployed
firewalls is to discard IPv6 fragments. firewalls is to discard IPv6 fragments.
In one recent study [BLACKHOLES], two researchers utilized a In one recent study [BLACKHOLES], two researchers utilized a
measurement network to measure fragment filtering. They sent measurement network to measure fragment filtering. They sent
packets, fragmented to the minimum MTU of 1280, to 502 IPv6 enabled packets, fragmented to the minimum MTU of 1280, to 502 IPv6-enabled
and reachable probes. They found that during any given trial period, and reachable probes. They found that during any given trial period,
ten percent of the probes did not receive fragmented packets. ten percent of the probes did not receive fragmented packets.
Thus this problem is valid for both IPv4 and IPv6 and may be caused Thus, this problem is valid for both IPv4 and IPv6 and may be caused
either by deficiency of network devices or by operational choice. by either deficiency of network devices or operational choice.
1.2. Proposed solution 1.2. Proposed Solution
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 IKEv2 itself, replacing them by fragmentation of large messages by IKEv2 itself and replace them with
series of smaller messages. In this case the resulting IP Datagrams a series of smaller messages. In this case, the resulting IP
will be small enough so that no fragmentation on IP level will take datagrams will be small enough so that no fragmentation at the IP
place. level will take place.
The primary goal of this solution is to allow IKEv2 to operate in The primary goal of this solution is to allow IKEv2 to operate in
environments, that might block IP fragments. This goal does not environments that might block IP fragments. This goal does not
assume that IP fragmentation should be avoided completely, but only assume that IP fragmentation should be avoided completely, but only
in those cases when it interferes with IKE operations. However this in those cases when it interferes with IKE operations. However, this
solution could be used to avoid IP fragmentation in all situations solution could be used to avoid IP fragmentation in all situations
where fragmentation within IKE is applicable, as it is recommended in where fragmentation within IKE is applicable, as recommended in
Section 3.2 of [RFC5405]. Avoiding IP fragmentation would be Section 3.2 of [RFC5405]. Avoiding IP fragmentation would be
beneficial for IKEv2 in general. Security Considerations Section of beneficial for IKEv2 in general. The Security Considerations section
[IKEv2] mentions exhausting of the IP reassembly buffers as one of of [RFC7296] mentions exhaustion of the IP reassembly buffers as one
the possible attacks on the protocol. In the paper [DOSUDPPROT] of the possible attacks on the protocol. In [DOSUDPPROT], several
several aspects of attacks on IKE using IP fragmentation are aspects of attacks on IKE using IP fragmentation are discussed, and
discussed, and one of the defenses it proposes is to perform one of the defenses it proposes is to perform fragmentation within
fragmentation within IKE similarly to the solution described in this IKE, similar to the solution described in this document.
document.
1.3. Conventions Used in This Document 1.3. 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 IKEv2 message into a set The idea of the protocol described in this document is to split large
of smaller ones, called IKE Fragment Messages. Fragmentation takes IKEv2 messages into a set of smaller ones, called IKE Fragment
place before the original message is encrypted and authenticated, so messages. Fragmentation takes place before the original message is
that each IKE Fragment Message receives individual protection. On encrypted and authenticated, so that each IKE Fragment message
the receiving side IKE Fragment Messages are collected, verified, receives individual protection. On the receiving side, IKE Fragment
decrypted and merged together to get the original message before messages are collected, verified, decrypted, and merged together to
encryption. See Appendix A for design rationale. get the original message before encryption. See Appendix A for
details on design rationale.
2.2. Limitations 2.2. Limitations
Since IKE Fragment Messages are cryptographically protected, SK_a and Since IKE Fragment messages are cryptographically protected, SK_a and
SK_e must already be calculated. In general, it means that original SK_e must already be calculated. In general, it means that the
message can be fragmented if and only if it contains an Encrypted original message can be fragmented if and only if it contains an
Payload. Encrypted payload.
This implies that messages of the IKE_SA_INIT Exchange cannot be This implies that messages of the IKE_SA_INIT exchange cannot be
fragmented. In most cases this is not a problem because IKE_SA_INIT fragmented. In most cases, this is not a problem because IKE_SA_INIT
messages are usually small enough to avoid IP fragmentation. But in messages are usually small enough to avoid IP fragmentation. But in
some cases (advertising a badly structured long list of algorithms, some cases (advertising a badly structured long list of algorithms,
using large MODP Groups, etc.) these messages may become fairly large using large Modular Exponentiation (MODP) groups, etc.), these
and get fragmented by IP level. In this case the described solution messages may become fairly large and get fragmented at the IP level.
will not help. In this case, the solution described in this document will not help.
Among existing IKEv2 extensions, messages of IKE_SESSION_RESUME Among existing IKEv2 extensions, messages of an IKE_SESSION_RESUME
Exchange, defined in [RFC5723], cannot be fragmented either. See exchange, as defined in [RFC5723], cannot be fragmented either. See
Section 3 for details. Section 3 for details.
Another limitation is that the minimal size of IP Datagram bearing Another limitation is that the minimum size of an IP datagram bearing
IKE Fragment Message is about 100 bytes depending on the algorithms an IKE Fragment message is about 100 bytes, depending on the
employed. According to [RFC0791] the minimum IPv4 Datagram size that algorithms employed. According to [RFC0791], the minimum IPv4
is guaranteed not to be further fragmented is 68 bytes. So, even the datagram size that is guaranteed not to be further fragmented is
smallest IKE Fragment Messages could be fragmented by IP level in 68 bytes. So, even the smallest IKE Fragment messages could be
some circumstances. But such extremely small PMTU sizes are very fragmented at the IP level in some circumstances. But such extremely
rare in real life. small Path MTU (PMTU) sizes are very rare in real life.
2.3. Negotiation 2.3. Negotiation
The Initiator indicates its support for the IKE Fragmentation and The initiator indicates its support for IKE fragmentation and
willingness to use it by including Notification Payload of type willingness to use it by including a Notification payload of type
IKEV2_FRAGMENTATION_SUPPORTED in IKE_SA_INIT request message. If IKEV2_FRAGMENTATION_SUPPORTED in the IKE_SA_INIT request message. If
Responder also supports this extension and is willing to use it, it the responder also supports this extension and is willing to use it,
includes this notification in response message. it includes this notification in the response message.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SAi1, KEi, Ni, HDR, SAi1, KEi, Ni,
[N(IKEV2_FRAGMENTATION_SUPPORTED)] --> [N(IKEV2_FRAGMENTATION_SUPPORTED)] -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ], <-- HDR, SAr1, KEr, Nr, [CERTREQ],
[N(IKEV2_FRAGMENTATION_SUPPORTED)] [N(IKEV2_FRAGMENTATION_SUPPORTED)]
The Notify payload is formatted as follows: The Notify payload is formatted as follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type | |Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Security Parameter
Index (SPI) is present.
o Notify Message Type (2 octets) - MUST be xxxxx, the value assigned o Notify Message Type (2 octets) - MUST be 16430, the value assigned
for IKEV2_FRAGMENTATION_SUPPORTED notification. for the IKEV2_FRAGMENTATION_SUPPORTED notification.
This Notification contains no data. This notification contains no data.
2.4. Using IKE Fragmentation 2.4. Using IKE Fragmentation
The IKE Fragmentation MUST NOT be used unless both peers have IKE fragmentation MUST NOT be used unless both peers have indicated
indicated their support for it. After that it is up to the Initiator their support for it. After that, it is up to the initiator of each
of each exchange to decide whether or not to use it. The Responder exchange to decide whether or not to use it. The responder usually
usually replies in the same form as the request message, but other replies in the same form as the request message, but other
considerations might override this. considerations might override this.
The Initiator can employ various policies regarding the use of IKE The initiator can employ various policies regarding the use of IKE
Fragmentation. It might first try to send an unfragmented message fragmentation. It might first try to send an unfragmented message
and resend it as fragmented only if no complete response is received and resend it as fragmented only if no complete response is received
even after several retransmissions. Alternatively, it might choose even after several retransmissions. Alternatively, it might choose
always to send fragmented messages (but see Section 3), or it might to always send fragmented messages (however, see Section 3), or it
fragment only large messages and messages that are expected to result might fragment only large messages and messages that are expected to
in large responses. result in large responses.
The following general guidelines apply: The following general guidelines apply:
o If either peer has information that a part of the transaction is o If either peer has information that a part of the transaction is
likely to be fragmented at the IP layer, causing interference with likely to be fragmented at the IP layer, causing interference with
the IKE exchange, that peer SHOULD use IKE Fragmentation. This the IKE exchange, that peer SHOULD use IKE fragmentation. This
information might be passed from a lower layer, provided by information might be passed from a lower layer, provided by
configuration, or derived through heuristics. Examples of configuration, or derived through heuristics. Examples of
heuristics are the lack of a complete response after several heuristics are the lack of a complete response after several
retransmissions for the Initiator, and receiving repeated retransmissions for the initiator, and receiving repeated
retransmissions of the request for the Responder. retransmissions of the request for the responder.
o If either peer knows that IKE Fragmentation has been used in a o If either peer knows that IKE fragmentation has been used in a
previous exchange in the context of the current IKE SA, that peer previous exchange in the context of the current IKE SA, that peer
SHOULD continue the use of IKE Fragmentation for the messages that SHOULD continue to use IKE fragmentation for the messages that are
are larger than the current fragmentation threshold (see larger than the current fragmentation threshold (see
Section 2.5.1). Section 2.5.1).
o IKE Fragmentation SHOULD NOT be used in cases where IP-layer o IKE fragmentation SHOULD NOT be used in cases where IP-layer
fragmentation of both the request and response messages is fragmentation of both the request and response messages is
unlikely. For example, there is no point in fragmenting Liveness unlikely. For example, there is no point in fragmenting liveness
Check messages. check messages.
o If none of the above apply, the Responder SHOULD respond in the o If none of the above apply, the responder SHOULD respond in the
same form (fragmented or not) as the request message it is same form (fragmented or not) as the request message to which it
responding to. Note that the other guidelines might override this is responding. Note that the other guidelines might override this
because of information or heuristics available to the Responder. because of information or heuristics available to the responder.
In most cases IKE Fragmentation will be used in the IKE_AUTH In most cases, IKE fragmentation will be used in the IKE_AUTH
Exchange, especially if certificates are employed. exchange, especially if certificates are employed.
2.5. Fragmenting Message 2.5. Fragmenting Message
Only messages that contain an Encrypted Payload are subject for IKE Only messages that contain an Encrypted payload are subject to IKE
Fragmentation. For the purpose of IKE Fragment Messages construction fragmentation. For the purpose of construction of IKE Fragment
original (unencrypted) content of the Encrypted Payload is split into messages, the original (unencrypted) content of the Encrypted payload
chunks. The content is treated as a binary blob and is split is split into chunks. The content is treated as a binary blob and is
regardless of inner Payloads boundaries. Each of resulting chunks is split regardless of the boundaries of inner payloads. Each of the
treated as an original content of the Encrypted Fragment Payload and resulting chunks is treated as an original content of the Encrypted
is then encrypted and authenticated. Thus, the Encrypted Fragment Fragment payload and is then encrypted and authenticated. Thus, the
Payload contains a chunk of the original content of the Encrypted Encrypted Fragment payload contains a chunk of the original content
Payload in encrypted form. The cryptographic processing of the of the Encrypted payload in encrypted form. The cryptographic
Encrypted Fragment Payload is identical to Section 3.14 of [IKEv2], processing of the Encrypted Fragment payload is identical to that
as well as documents updating it for particular algorithms or modes, described in Section 3.14 of [RFC7296], as well as documents updating
such as [RFC5282]. such processing for particular algorithms or modes, such as
[RFC5282].
The Encrypted Fragment Payload, similarly to the Encrypted Payload, As is the case for the Encrypted payload, the Encrypted Fragment
if present in a message, MUST be the last payload in the message. payload, if present in a message, MUST be the last payload in the
message.
The Encrypted Fragment Payload is denoted SKF{...} and its payload The Encrypted Fragment payload is denoted SKF{...}, and its payload
type is XXX (TBA by IANA). This payload is also called the type is 53. This payload is also called the "Encrypted and
"Encrypted and Authenticated Fragment" payload. Authenticated Fragment" payload.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 26 skipping to change at page 7, line 37
| | 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 Payload (1 octet) - in the very first fragment (with Fragment o Next Payload (1 octet) - in the very first fragment (with Fragment
Number equal to 1) this field MUST be set to Payload Type of the Number equal to 1), this field MUST be set to the payload type of
first inner Payload (similarly to the Encrypted Payload). In the the first inner payload (the same as for the Encrypted payload).
rest fragments MUST be set to zero. In the rest of the Fragment messages (with Fragment Number greater
than 1), this field MUST be set to zero.
o Fragment Number (2 octets) - current fragment number starting from o Fragment Number (2 octets, unsigned integer) - current Fragment
1. This field MUST be less than or equal to the next field, Total message number, starting from 1. This field MUST be less than or
Fragments. This field MUST NOT be zero. equal to the next field (Total Fragments). This field MUST NOT be
zero.
o Total Fragments (2 octets) - number of fragments original message o Total Fragments (2 octets, unsigned integer) - number of Fragment
was divided into. This field MUST NOT be zero. With PMTU messages into which the original message was divided. This field
discovery this field plays additional role. See Section 2.5.2 for MUST NOT be zero. With PMTU discovery, this field plays an
details. additional role. See Section 2.5.2 for details.
The other fields are identical to those specified in Section 3.14 of The other fields are identical to those specified in Section 3.14 of
[IKEv2]. [RFC7296].
When prepending IKE Header to the IKE Fragment Messages it MUST be When prepending the IKE header to the IKE Fragment messages, it MUST
taken intact from the original message, except for the Length and the be taken intact from the original message, except for the Length and
Next Payload fields. The Length field is adjusted to reflect the Next Payload fields. The Length field is adjusted to reflect the
length of the constructed message and the Next Payload field is set length of the IKE Fragment message being constructed, and the Next
to the payload type of the first Payload in constructed message (in Payload field is set to the payload type of the first payload in that
most cases it will be Encrypted Fragment Payload). After prepending message (in most cases, it will be the Encrypted Fragment payload).
IKE Header and all Payloads that possibly precede Encrypted Payload After prepending the IKE header and all payloads that possibly
in original message (if any, see Section 2.5.3), the resulting precede the Encrypted payload in the original message (if any; see
messages are sent to the peer. Section 2.5.3), the resulting messages are sent to the peer.
Below is an example of fragmenting a message. Below is an example of fragmenting a 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. Selecting Fragment Size 2.5.1. Selecting Fragment Size
When splitting content of Encrypted Payload into chunks sender SHOULD When splitting the content of an Encrypted payload into chunks, the
choose their size so, that resulting IP Datagrams be smaller than sender SHOULD choose their size so that the resulting IP datagrams
some fragmentation threshold. Implementations may calculate will be smaller than some fragmentation threshold. Implementations
fragmentation threshold using various sources of information. may calculate the fragmentation threshold using various sources of
information.
If the Sender has information about PMTU size it SHOULD use it. The If the sender has information about the PMTU size, it SHOULD use it.
Responder in the exchange may use maximum size of received IKE The responder in the exchange may use the maximum size of the
Fragment Message IP Datagrams as threshold when constructing received IKE Fragment message IP datagrams as a threshold when
fragmented response. Successful completion of previous exchanges constructing a fragmented response. Successful completion of
(including those exchanges, that cannot employ IKE Fragmentation, previous exchanges (including those exchanges that cannot employ IKE
e.g. IKE_SA_INIT) may be an indication, that fragmentation threshold fragmentation, e.g., IKE_SA_INIT) may be an indication that the
can be set to the size of the largest of already sent messages. fragmentation threshold can be set to the size of the largest message
of those messages already sent.
Otherwise for messages to be sent over IPv6 it is RECOMMENDED to use Otherwise, for messages to be sent over IPv6, it is RECOMMENDED that
value 1280 bytes as a maximum IP Datagram size ([RFC2460]). For a value of 1280 bytes as a maximum IP datagram size be used
messages to be sent over IPv4 it is RECOMMENDED to use value 576 ([RFC2460]). For messages to be sent over IPv4, it is RECOMMENDED
bytes as a maximum IP Datagram size. Presence of tunnels on the path that a value of 576 bytes as a maximum IP datagram size be used. The
may reduce these values. Implementations may use other values if presence of tunnels on the path may reduce these values.
they are appropriate in current environment. Implementations may use other values if they are appropriate in the
current environment.
According to [RFC0791] the minimum IPv4 Datagram size that is 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 a small value for the solution
in this document. Using 576 bytes is a compromise - the value is described in this document. Using 576 bytes is a compromise -- the
large enough for the presented solution and small enough to avoid IP value is large enough for the presented solution and small enough to
fragmentation in most situations. Several other UDP-based protocol avoid IP fragmentation in most situations. Several other UDP-based
assume the value 576 bytes as a safe low limit for IP Datagrams size protocols (Syslog, DNS, etc.) use 576 bytes as a safe low limit for
(Syslog, DNS, etc.). IP datagram size.
See Appendix B for correlation between IP Datagram size and Encrypted See Appendix B for correlation between IP datagram size and Encrypted
Payload content size. payload content size.
2.5.2. PMTU Discovery 2.5.2. PMTU Discovery
The amount of traffic that IKE endpoint produces during lifetime of The amount of traffic that the IKE endpoint produces during the
IKE SA is fairly modest - usually it is below one hundred kBytes lifetime of an IKE SA is fairly modest -- it is usually below 100 KB
within a period of several hours. Most of this traffic consists of within a period of several hours. Most of this traffic consists of
relatively short messages - usually below several hundred bytes. In relatively short messages -- usually below several hundred bytes. In
most cases the only time when IKE endpoints exchange messages of most cases, the only time when IKE endpoints exchange messages of
several kBytes in size is IKE SA establishment and often each several KB in size is IKE SA establishment, and often each endpoint
endpoint sends exactly one such message. sends exactly one such message.
For the reasons articulated above implementing PMTU discovery in IKE For the reasons articulated above, implementing PMTU discovery in IKE
is OPTIONAL. It is believed that using the values recommended in is OPTIONAL. It is believed that using the values recommended in
Section 2.5.1 as fragmentation threshold will be sufficient in most Section 2.5.1 as a fragmentation threshold will be sufficient in most
cases. Using these values could lead to suboptimal fragmentation, cases. Using these values could lead to suboptimal fragmentation,
but it is acceptable given the amount of traffic IKE produces. but it is acceptable given the amount of traffic IKE produces.
Implementations may support PMTU discovery if there are good reasons Implementations may support PMTU discovery if there are good reasons
to do it (for example if it is intended to be used in environments to do it (for example, if they are intended to be used in
where MTU size is possible to be less that values listed in environments where the MTU size might be less than the values listed
Section 2.5.1). in Section 2.5.1).
PMTU discovery in IKE follows recommendations given in Section 10.4 PMTU discovery in IKE follows recommendations given in Section 10.4
of [RFC4821] with the difference, induced by the specialties of IKE of [RFC4821] with some modifications, induced by the distinctive
listed above. The difference is that the PMTU search is performed features of IKE listed above. The difference is that the PMTU search
downward, while in [RFC4821] it is performed upward. The reason for is performed downward, while in [RFC4821] it is performed upward.
this change is that IKE usually sends large messages only when IKE SA The reason for this change is that IKE usually sends large messages
is being established and in many cases there is only one such only when the IKE SA is being established, and in many cases there is
message. If the probing were performed upward this message would be only one such message. If the probing were performed upward, this
fragmented using the smallest allowable threshold, and usually all message would be fragmented using the smallest allowable threshold,
other messages are small enough to avoid IP fragmentation, so there and usually all other messages are small enough to avoid IP
would be little value to continue probing. fragmentation, so continued probing would be of little value.
It is the Initiator of the exchange, who performs PMTU discovery. It It is the initiator of the exchange who performs PMTU discovery.
is done by probing several values of fragmentation threshold. This is done by probing several values of fragmentation threshold.
Implementations MUST be prepared to probe in every exchange that Implementations MUST be prepared to probe in every exchange that
utilizes IKE Fragmentation to deal with possible changes of path MTU utilizes IKE fragmentation to deal with possible changes in path MTU
over time. While doing probes, it MUST start from larger values and over time. While doing probes, it MUST start from larger values and
refragment original message using next smaller value of threshold if refragment the original message, using the next smaller value of the
it did not receive response in a reasonable time after several threshold if it did not receive a response in a reasonable time after
retransmissions. The exact number of retransmissions and length of several retransmissions. The exact number of retransmissions and
timeouts are not covered in this specification because they do not length of timeouts are not covered in this specification because they
affect interoperability. However, the timeout interval is supposed do not affect interoperability. However, the timeout interval is
to be relatively short, so that unsuccessful probes would not delay supposed to be relatively short, so that unsuccessful probes would
IKE operations too much. Performing few retries within several not delay IKE operations too much. Performing a few retries within
seconds for each probe seems appropriate, but different environments several seconds for each probe seems appropriate, but different
may require different rules. When starting new probe node MUST reset environments may require different rules. When starting a new probe,
its retransmission timers so, that if it employs exponential back- the node MUST reset its retransmission timers so that if it employs
off, the timers will start over. After reaching the smallest allowed exponential back-off the timers will start over. After reaching the
value for the fragmentation threshold an implementation MUST continue smallest allowed value for the fragmentation threshold, an
retransmitting until either exchange completes or times out using implementation MUST continue retransmitting until the exchange either
timeout interval from Section 2.4 of [IKEv2]. completes or times out using some timeout interval as discussed in
Section 2.4 of [RFC7296].
PMTU discovery in IKE is supposed to be coarse-grained, i.e. it is PMTU discovery in IKE is supposed to be coarse-grained, i.e., it is
expected, that node will try only few fragmentation thresholds, in expected that a node will try only a few fragmentation thresholds in
order to minimize delays caused by unsuccessful probes. If no order to minimize delays caused by unsuccessful probes. If path MTU
information about path MTU is known yet, endpoint may start probing information is not yet available, the endpoint may use the link MTU
from link MTU size. In the following exchanges node should start size when it starts probing. In subsequent exchanges, the node
from the current value of fragmentation threshold. should start with the current value of the fragmentation threshold.
If an implementation is capable to receive ICMP error messages it can If an implementation is capable of receiving ICMP error messages, it
additionally utilize classic PMTU discovery methods, described in can additionally utilize classic PMTU discovery methods, as described
[RFC1191] and [RFC1981]. In particular, if the Initiator receives in [RFC1191] and [RFC1981]. In particular, if the initiator receives
Packet Too Big error in response to the probe, and it contains a Packet Too Big error in response to the probe, and it contains a
smaller value, than current fragmentation threshold, then the smaller value than the current fragmentation threshold, then the
Initiator SHOULD stop retransmitting the probe and SHOULD select new initiator SHOULD stop retransmitting the probe and SHOULD select a
value for fragmentation threshold that is less than or equal to the new value for the fragmentation threshold that is less than or equal
value from the ICMP message and meets the requirements listed below. to the value from the ICMP message and meets the requirements listed
below.
In case of PMTU discovery Total Fragments field is used to In the case of PMTU discovery, the Total Fragments field is used to
distinguish between different sets of fragments, i.e. the sets that distinguish between different sets of fragments, i.e., the sets that
were created by fragmenting original message using different were created by fragmenting the original message using different
fragmentation thresholds. Since sender starts from larger fragments fragmentation thresholds. Since the sender starts from larger
and then make them smaller, the value in Total Fragments field fragments and then makes them smaller, the value in the Total
increases with each new probe. When selecting next smaller value for Fragments field increases with each new probe. When selecting the
fragmentation threshold, sender MUST ensure that the value in Total next smaller value for the fragmentation threshold, the sender MUST
Fragments field is really increased. This requirement should not be ensure that the value in the Total Fragments field is really
a problem for the sender, because PMTU discovery in IKE is supposed increased. This requirement should not be a problem for the sender,
to be coarse-grained, so difference between previous and next because PMTU discovery in IKE is supposed to be coarse-grained, so
fragmentation thresholds should be significant anyway. The necessity the difference between previous and next fragmentation thresholds
to distinguish between the sets is vital for receiver since receiving should be significant anyway. The need to distinguish between the
valid fragment from newer set means that it have to start sets is vital for the receiver, since receiving a valid fragment from
reassembling over and not to mix fragments from different sets. a newer set means that it has to start the reassembly process over
and not mix fragments from different sets.
2.5.3. Fragmenting Messages containing unprotected Payloads 2.5.3. Fragmenting Messages Containing Unprotected Payloads
Currently there are no IKEv2 exchanges that define messages, Currently, there are no IKEv2 exchanges that define messages,
containing both unprotected payloads and payloads, protected by containing both unprotected payloads and payloads, that are protected
Encrypted Payload. However IKEv2 does not prohibit such by the Encrypted payload. However, IKEv2 does not prohibit such
construction. If some future IKEv2 extension defines such a message construction. If some future IKEv2 extension defines such a message
and it needs to be fragmented, all unprotected payloads MUST be and it needs to be fragmented, all unprotected payloads MUST be
placed in the first fragment (with Fragment Number field equal to 1), placed in the first fragment (with the Fragment Number field equal to
along with Encrypted Fragment Payload, which MUST be present in every 1), along with the Encrypted Fragment payload, which MUST be present
IKE Fragment Message and be the last payload in it. in every IKE Fragment message and be the last payload in it.
Below is an example of fragmenting message, containing both protected Below is an example of a fragmenting message that contains both
and unprotected Payloads. protected and unprotected 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 the size of each IP Datagram bearing IKE Fragment Messages Note that the size of each IP datagram bearing IKE Fragment messages
should not exceed fragmentation threshold, including the first one, should not exceed the fragmentation threshold, including the first
that contains unprotected Payloads. This will reduce the size of one, that contains unprotected payloads. This will reduce the size
Encrypted Fragment Payload content in the first IKE Fragment Message of the Encrypted Fragment payload content in the first IKE Fragment
to accommodate all unprotected Payloads. In extreme case Encrypted message to accommodate all unprotected payloads. In an extreme case,
Fragment Payload will contain no data, but it still must be present the Encrypted Fragment payload will contain no data, but it still
in the message, because only its presence allows receiver to must be present in the message, because only its presence allows the
determine that sender have used IKE Fragmentation. receiver to determine that the sender has used IKE fragmentation.
2.6. Receiving IKE Fragment Message 2.6. Receiving IKE Fragment Message
The Receiver identifies the IKE Fragment Message by the presence of The receiver identifies the IKE Fragment message by the presence of
an Encrypted Fragment Payload in it. In most cases it will be the an Encrypted Fragment payload in it. In most cases, it will be the
first and the only payload in the message, however this may not be first and only payload in the message; however, this may not be true
true for some hypothetical IKE exchanges (see Section 2.5.3) for some hypothetical IKE exchanges (see Section 2.5.3).
Upon receiving the IKE Fragment Message the following actions are Upon receiving the IKE Fragment message, the following actions are
performed: performed:
o Check message validity - in particular, check whether the values o Check message validity - in particular, check whether the values
in the Fragment Number and the Total Fragments fields in the in the Fragment Number and the Total Fragments fields in the
Encrypted Fragment Payload are valid. The following tests need to Encrypted Fragment payload are valid. The following tests need to
be performed. be performed.
* check that the Fragment Number and the Total Fragments fields * check that the Fragment Number and the Total Fragments fields
contain non-zero values contain non-zero values
* check that the value in the Fragment Number field is less than * check that the value in the Fragment Number field is less than
or equal to the value in the Total Fragments field or equal to the value in the Total Fragments field
* if reassembling has already started, check that the value in * if reassembling has already started, check that the value in
the Total Fragments field is equal to or greater than Total the Total Fragments field is equal to or greater than the Total
Fragments field in the fragments that have already been stored Fragments field in the fragments that have already been stored
in the reassembling queue in the reassembling queue
If any of this tests fails the message MUST be silently discarded. If any of these tests fail, the 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 a replay. If IKE Fragment message with the same Message ID, not a replay. If an IKE Fragment message with the same Message
same Fragment Number and same Total Fragments fields is already ID, Fragment Number, and Total Fragments fields is already present
present in the reassembling queue, this message is considered a in the reassembling queue, this message is considered a replay and
replay and MUST be silently discarded. MUST be silently discarded.
o Verify IKE Fragment Message authenticity by checking ICV in o Verify IKE Fragment message authenticity by checking the Integrity
Encrypted Fragment Payload. If ICV check fails message MUST be Check Value (ICV) in the Encrypted Fragment payload. If the ICV
silently discarded. check fails, the message MUST be silently discarded.
o If reassembling is not finished yet and Total Fragments field in o If reassembling is not finished yet and the Total Fragments field
received fragment is greater than this field in those fragments, in the received fragment is greater than the Total Fragments field
that are in the reassembling queue, receiver MUST discard all in those fragments that are in the reassembling queue, the
received fragments and start reassembling over with just received receiver MUST discard all received fragments and start the
IKE Fragment Message. reassembly process over with just the received IKE Fragment
message.
o Store message in the reassembling queue waiting for the rest of o Store the message in the reassembling queue waiting for the rest
fragments to arrive. of the fragments to arrive.
When all IKE Fragment Messages (as indicated in the Total Fragments When all IKE Fragment messages (as indicated in the Total Fragments
field) are received, the decrypted content of all Encrypted Fragment field) are received, the decrypted content of all Encrypted Fragment
Payloads is merged together to form content of original Encrypted payloads is merged together to form the content of the original
Payload, and, therefore, along with IKE Header and unprotected Encrypted payload and, therefore, along with the IKE header and
Payloads (if any), original message. Then it is processed as if it unprotected payloads (if any), the original message. Then, it is
was received, verified and decrypted as regular IKE message. processed as if it was received, verified, and decrypted as a regular
IKE message.
If receiver does not get all IKE fragments needed to reassemble the If the receiver does not get all IKE fragments needed to reassemble
original Message within a timeout interval, it MUST discard all IKE the original message within a timeout interval, it MUST discard all
Fragment Messages received so far for the exchange. The next actions IKE Fragment messages received so far for the exchange. The next
depend on the role of receiver in the exchange. actions depend on the role of the receiver in the exchange.
o The Initiator acts as described in Section 2.1 of [IKEv2]. It o The initiator acts as described in Section 2.1 of [RFC7296]. It
either retransmits the fragmented request Message or deems IKE SA either retransmits the fragmented request message or deems the IKE
to have failed and deletes it. The number of retransmits and SA to have failed and deletes it. The number of retransmits and
length of timeouts for the Initiator are not covered in this length of timeouts for the initiator are not covered in this
specification since they are assumed to be the same as in regular specification, since they are assumed to be the same as in a
IKEv2 exchange and are discussed in Section 2.4 of [IKEv2]. regular IKEv2 exchange and are discussed in Section 2.4 of
[RFC7296].
o The Responder in this case acts as if no request message was o The responder in this case acts as if no request message was
received. It would delete any memory of the incomplete request received. It would delete any memory of the incomplete request
message, and not treat it as an IKE SA failure. The reassembling message and not treat it as an IKE SA failure. It is RECOMMENDED
timeout for the Responder is RECOMMENDED to be equal to the time that the reassembling timeout for the responder be equal to the
interval that the implementation waits before completely giving up time interval that the implementation waits before completely
when acting as Initiator of exchange. Section 2.4 of [IKEv2] giving up when acting as the initiator of an exchange.
gives recommendations for selecting this interval. Section 2.4 of [RFC7296] gives recommendations for selecting this
Implementations can use a shorter timeout to conserve memory. interval. Implementations can use a shorter timeout to conserve
memory.
2.6.1. Replay Detection and Retransmissions 2.6.1. Replay Detection and Retransmissions
According to [IKEv2] implementations must reject message with the According to Section 2.2 of [RFC7296], the Message ID is used, in
same Message ID as it has seen before (taking into consideration particular, to identify retransmissions of IKE messages. Each
Response bit). This logic has already been updated by [RFC6311], request or response message, sent by either side, must have a unique
which deliberately allows any number of messages with zero Message Message ID, or be considered a retransmission otherwise. This logic
ID. This document also updates this logic for the situations, when has already been updated by [RFC6311], which deliberately allows any
IKE Fragmentation is in use. number of messages with zero Message ID. This document also updates
this logic for those situations where IKE fragmentation is in use.
If incoming message contains Encrypted Fragment Payload, the values If an incoming message contains an Encrypted Fragment payload, the
of Fragment Number and Total Fragments fields MUST be used along with values of the Fragment Number and Total Fragments fields MUST be used
Message ID to detect retransmissions and replays. along with the Message ID to detect retransmissions and replays.
If Responder receives retransmitted fragment of request when it has If the responder receives a retransmitted fragment of a request when
already processed that request and has sent back a response, that it has already processed that request and has sent back a response,
event MUST only trigger retransmission of the response message that event MUST only trigger a retransmission of the response message
(fragmented or not) if Fragment Number field in received fragment is (fragmented or not) if the Fragment Number field in the received
set to 1 and MUST be ignored otherwise. fragment is set to 1; otherwise, it MUST be ignored.
3. Interaction with other IKE extensions 3. Interaction with Other IKE Extensions
IKE Fragmentation is compatible with most of IKE extensions, such as IKE fragmentation is compatible with most IKE extensions, such as IKE
IKE Session Resumption ([RFC5723]), Quick Crash Detection Method Session Resumption ([RFC5723]), the Quick Crash Detection Method
([RFC6290]) and so on. It neither affect their operation, nor is ([RFC6290]), and so on. It neither affects their operation nor is
affected by them. It is believed that IKE Fragmentation will also be affected by them. It is believed that IKE fragmentation will also be
compatible with future IKE extensions, if they follow general compatible with future IKE extensions, if they follow general
principles of formatting, sending and receiving IKE messages, principles of formatting, sending, and receiving IKE messages, as
described in [IKEv2]. described in [RFC7296].
When IKE Fragmentation is used with IKE Session Resumption When IKE fragmentation is used with IKE Session Resumption
([RFC5723]), messages of IKE_SESSION_RESUME Exchange cannot be ([RFC5723]), messages of an IKE_SESSION_RESUME exchange cannot be
fragmented since they do not contain Encrypted Payload. These fragmented, since they do not contain an Encrypted payload. These
messages may be large due to the ticket size. To avoid IP messages may be large due to the ticket size. To avoid IP
Fragmentation in this situation it is recommended to use smaller fragmentation in this situation, it is recommended that smaller
tickets, e.g. by utilizing "ticket by reference" approach instead of tickets be used, e.g., by utilizing a "ticket by reference" approach
"ticket by value". instead of "ticket by value".
One exception that requires a special care is Protocol Support for Protocol Support for High Availability of IKEv2/IPsec, described in
High Availability of IKEv2/IPsec ([RFC6311]). Since it deliberately [RFC6311], requires special care when deciding whether to fragment an
allows any number of synchronization exchanges to have the same IKE message or not. Since it deliberately allows any number of
Message ID, namely zero, standard IKEv2 replay detection logic, based synchronization exchanges to have the same Message ID, namely zero,
on checking Message ID is not applicable for such messages, and standard IKEv2 replay detection logic, based on checking the Message
receiver has to check message content to detect replays. When ID, is not applicable for such messages, and the receiver has to
implementing IKE Fragmentation along with [RFC6311], IKE Message ID check message content to detect replays. When implementing IKE
Synchronization messages MUST NOT be sent fragmented to simplify fragmentation along with [RFC6311], IKE Message ID Synchronization
receiver's task of detecting replays. Fortunately, these messages messages MUST NOT be sent fragmented, to simplify the receiver's task
are small and there is no point in fragmenting them anyway. of detecting replays. Fortunately, these messages are small, and
there is no point in fragmenting them anyway.
4. Transport Considerations 4. Transport Considerations
With IKE Fragmentation if any single IKE Fragment Message get lost, With IKE fragmentation, if any single IKE Fragment message gets lost,
receiver becomes unable to reassemble original Message. So, in the receiver becomes unable to reassemble the original message. So,
general, using IKE Fragmentation implies higher probability for the in general, using IKE fragmentation implies a higher probability that
Message not to be delivered to the peer. Although in most network the message will not be delivered to the peer. Although in most
environments the difference will be insignificant, on some lossy network environments the difference will be insignificant, on some
networks it may become noticeable. When using IKE Fragmentation lossy networks it may become noticeable. When using IKE
implementations MAY use longer timeouts and do more retransmits than fragmentation, implementations MAY use longer timeouts and do more
usual before considering peer dead. retransmits than usual before considering the peer dead.
Note that Fragment Messages are not individually acknowledged. The Note that Fragment messages are not individually acknowledged. The
response Fragment Messages are sent back all together only when all response Fragment messages are all sent back together only when all
fragments of request are received, the original request Message is fragments of the request are received, and the original request
reassembled and successfully processed. message is reassembled and successfully processed.
5. Security Considerations 5. 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 the base IKEv2 protocol described in [IKEv2]. This same as those for the base IKEv2 protocol described in [RFC7296].
extension introduces Encrypted Fragment Payload to protect content of This extension introduces the Encrypted Fragment payload to protect
IKE Message Fragment. This allows receiver to individually check the content of an IKE Message Fragment. This allows the receiver to
authenticity of fragments, thus protecting peers from DoS attack. individually check the authenticity of fragments, thus protecting
peers from a DoS attack.
Security Considerations Section of [IKEv2] mentions possible attack The Security Considerations section of [RFC7296] mentions a possible
on IKE by exhausting of the IP reassembly buffers. The mechanism, attack on IKE where an attacker could prevent an exchange from
described in this document, allows IKE to avoid IP fragmentation and completing by exhausting the IP reassembly buffers. The mechanism
described in this document allows IKE to avoid IP fragmentation and
therefore increases its robustness to DoS attacks. therefore increases its robustness to DoS attacks.
The following attack is possible with IKE Fragmentation. An attacker The following attack is possible with IKE fragmentation. An attacker
can initiate IKE_SA_INIT Exchange, complete it, compute SK_a and SK_e can initiate an IKE_SA_INIT exchange, complete it, compute SK_a and
and then send a large, but still incomplete, set of IKE_AUTH SK_e, and then send a large but still incomplete set of IKE_AUTH
fragments. These fragments will pass the ICV check and will be fragments. These fragments will pass the ICV check and will be
stored in reassembly buffers, but since the set is incomplete, the stored in reassembly buffers, but since the set is incomplete, the
reassembling will never succeed and eventually will time out. If the reassembling will never succeed and eventually will time out. If the
set is large, this attack could potentially exhaust the receiver's set is large, this attack could potentially exhaust the receiver's
memory resources. memory resources.
To mitigate the impact of this attack, it is RECOMMENDED that To mitigate the impact of this attack, it is RECOMMENDED that the
receiver limits the number of fragments it stores in reassembling receiver limit the number of fragments it stores in the reassembling
queue so that the sum of the sizes of Encrypted Fragment Payload queue so that the sum of the sizes of Encrypted Fragment payload
contents (after decryption) for fragments that are already placed contents (after decryption) for fragments that are already placed
into the reassembling queue is less than some value that is into the reassembling queue is less than some value that is
reasonable for the implementation. If the peer sends so many reasonable for the implementation. If the peer sends so many
fragments that the above condition is not met, the receiver can fragments that the above condition is not met, the receiver can
consider this situation to be either attack or as broken sender consider this situation to be either an attack or a broken sender
implementation. In either case, the receiver SHOULD drop the implementation. In either case, the receiver SHOULD drop the
connection and discard all the received fragments. connection and discard all the received fragments.
This value can be predefined, can be a configurable option, or can be This value can be predefined, can be a configurable option, or can be
calculated dynamically depending on the receiver's memory load. Some calculated dynamically, depending on the receiver's memory load.
care should be taken when selecting this value because, if it is too Some care should be taken when selecting this value because if it is
small, it might prevent legitimate peer to establish IKE SA if the too small it might prevent a legitimate peer from establishing an IKE
size of messages it sends exceeds this value. It is NOT RECOMMENDED SA if the size of messages it sends exceeds this value. It is NOT
for this value to exceed 64 Kbytes because any IKE message before RECOMMENDED for this value to exceed 64 KB because any IKE message
fragmentation would likely be shorter than that. before fragmentation would likely be shorter than that.
If IKE fragments arrive in order, it is possible, but not advised, If IKE fragments arrive in order, it is possible, but not advised,
for receiver to parse the beginning of the message that is being for the receiver to parse the beginning of the message that is being
reassembled and extract the already available payloads before the reassembled and extract the already-available payloads before the
reassembly is complete. It can be dangerous to take any action based reassembly is complete. It can be dangerous to take any action based
on the content of these payloads, because the not yet received on the content of these payloads, because the fragments that have not
fragments might contain payloads that could change the meaning of yet been received might contain payloads that could change the
them (or could even make the whole message invalid) and this can meaning of them (or could even make the whole message invalid), and
potentially be exploited by an attacker. It is important to address this can potentially be exploited by an attacker. It is important to
this threat by ensuring all the fragments are received prior to parse address this threat by ensuring that all the fragments are received
reassembled message, as it described in Section 2.6. prior to parsing the reassembled message, as described in
Section 2.6.
6. IANA Considerations 6. IANA Considerations
This document defines new Payload in the "IKEv2 Payload Types" This document defines a new payload in the "IKEv2 Payload Types"
registry: registry:
<TBA> Encrypted and Authenticated Fragment SKF 53 Encrypted and Authenticated Fragment SKF
This document also defines new Notify Message Types in the "Notify
Message Types - Status Types" registry:
<TBA> IKEV2_FRAGMENTATION_SUPPORTED
7. Acknowledgements This document also defines a new Notify Message Type in the "IKEv2
Notify Message Types - Status Types" registry:
The author would like to thank Tero Kivinen, Yoav Nir, Paul Wouters, 16430 IKEV2_FRAGMENTATION_SUPPORTED
Yaron Sheffer, Joe Touch, Derek Atkins, Ole Troan and others for
their reviews and valuable comments. Thanks to Ron Bonica for
contributing text to the Introduction Section. Thanks to Paul
Hoffman and Barry Leiba for improving text clarity.
8. References 7. References
8.1. Normative References 7.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,
<http://www.rfc-editor.org/info/rfc2119>.
[IKEv2] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", draft-kivinen-ipsecme-ikev2-rfc5996bis-03 (work (IKEv2)", STD 79, RFC 7296, October 2014,
in progress), April 2014. <http://www.rfc-editor.org/info/rfc7296>.
[RFC6311] Singh, R., Kalyani, G., Nir, Y., Sheffer, Y., and D. [RFC6311] Singh, R., Kalyani, G., Nir, Y., Sheffer, Y., and D.
Zhang, "Protocol Support for High Availability of IKEv2/ Zhang, "Protocol Support for High Availability of IKEv2/
IPsec", RFC 6311, July 2011. IPsec", RFC 6311, July 2011,
<http://www.rfc-editor.org/info/rfc6311>.
8.2. Informative References 7.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, <http://www.rfc-editor.org/info/rfc791>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990, <http://www.rfc-editor.org/info/rfc1191>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996. for IP version 6", RFC 1981, August 1996,
<http://www.rfc-editor.org/info/rfc1981>.
[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,
<http://www.rfc-editor.org/info/rfc2460>.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007,
<http://www.rfc-editor.org/info/rfc4787>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007. Discovery", RFC 4821, March 2007,
<http://www.rfc-editor.org/info/rfc4821>.
[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption
Algorithms with the Encrypted Payload of the Internet Key Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol", RFC 5282, Exchange version 2 (IKEv2) Protocol", RFC 5282,
August 2008. August 2008, <http://www.rfc-editor.org/info/rfc5282>.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405, for Application Designers", BCP 145, RFC 5405,
November 2008. November 2008, <http://www.rfc-editor.org/info/rfc5405>.
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
January 2010. January 2010, <http://www.rfc-editor.org/info/rfc5723>.
[RFC6290] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A [RFC6290] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A
Quick Crash Detection Method for the Internet Key Exchange Quick Crash Detection Method for the Internet Key Exchange
Protocol (IKE)", RFC 6290, June 2011. Protocol (IKE)", RFC 6290, June 2011,
<http://www.rfc-editor.org/info/rfc6290>.
[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common Requirements for Carrier-Grade NATs and H. Ashida, "Common Requirements for Carrier-Grade NATs
(CGNs)", BCP 127, RFC 6888, April 2013. (CGNs)", BCP 127, RFC 6888, April 2013,
<http://www.rfc-editor.org/info/rfc6888>.
[FRAGDROP] [FRAGDROP] Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
M., and T. Taylor, "Why Operators Filter Fragments and M., and T. Taylor, "Why Operators Filter Fragments and
What It Implies", draft-taylor-v6ops-fragdrop-02 (work in What It Implies", Work in Progress, draft-taylor-v6ops-
progress), December 2013. fragdrop-02, December 2013.
[BLACKHOLES] [BLACKHOLES]
De Boer, M. and J. Bosma, "Discovering Path MTU black De Boer, M. and J. Bosma, "Discovering Path MTU black
holes on the Internet using RIPE Atlas", July 2012, <http: holes on the Internet using RIPE Atlas", July 2012,
//www.nlnetlabs.nl/downloads/publications/ <http://www.nlnetlabs.nl/downloads/publications/
pmtu-black-holes-msc-thesis.pdf>. pmtu-black-holes-msc-thesis.pdf>.
[DOSUDPPROT] [DOSUDPPROT]
Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS
protection for UDP-based protocols", ACM Conference on protection for UDP-based protocols", ACM Conference on
Computer and Communications Security, October 2003. Computer and Communications Security, October 2003.
Appendix A. Design rationale Appendix A. Design Rationale
The simplest approach to the IKE fragmentation would have been to The simplest approach to IKE fragmentation would have been to
fragment message that is fully formed and ready to be sent. But if fragment a message that is fully formed and ready to be sent.
message got fragmented after being encrypted and authenticated, this However, if a message got fragmented after being encrypted and
could open a possibility for a simple Denial of Service attack. The authenticated, this could make a simple DoS attack possible. The
attacker could infrequently emit forged but valid looking fragments attacker could infrequently emit forged but valid-looking fragments
into the network, and some of these fragments would be fetched by into the network, and some of these fragments would be fetched by the
receiver into the reassembling queue. Receiver could not distinguish receiver into the reassembling queue. The receiver would not be able
forged fragments from valid ones and could only determine that some to distinguish forged fragments from valid ones and would only be
of received fragments were forged when the whole message got able to determine that some of the received fragments were forged
reassembled and check for its authenticity failed. after the whole message was reassembled and its authenticity check
failed.
To prevent this kind of attack and also to reduce vulnerability to To prevent this kind of attack and also reduce vulnerability to some
some other kinds of DoS attacks it was decided to make fragmentation other kinds of DoS attacks, it was decided to perform fragmentation
before applying cryptographic protection to the message. In this before applying cryptographic protection to the message. In this
case each Fragment Message becomes individually encrypted and case, each Fragment message becomes individually encrypted and
authenticated, that allows receiver to determine forged fragments and authenticated; this allows the receiver to determine forged fragments
not to store them in the reassembling queue. and not store them in the reassembling queue.
Appendix B. Correlation between IP Datagram size and Encrypted Payload Appendix B. Correlation between IP Datagram Size and Encrypted Payload
content size Content Size
For IPv4 Encrypted Payload content size is less than IP Datagram size In the case of IPv4, the content size of the Encrypted Payload is
by the sum of the following values: less than the IP datagram size by the sum of the following values:
o IPv4 header size (typically 20 bytes, up to 60 if IP options are o IPv4 header size (typically 20 bytes, up to 60 if IP options are
present) present)
o UDP header size (8 bytes) o UDP header size (8 bytes)
o non-ESP marker size (4 bytes if present) o non-ESP (Encapsulating Security Payload) marker size (4 bytes if
present)
o IKE Header size (28 bytes) o IKE header size (28 bytes)
o Encrypted Payload header size (4 bytes) o Encrypted payload header size (4 bytes)
o IV size (varying) o initialization vector (IV) size (variable)
o padding and its size (at least 1 byte) o padding and its size (at least 1 byte)
o ICV size (varying) o ICV size (variable)
The sum may be estimated as 61..105 bytes + IV + ICV + padding. The sum may be estimated as 61..105 bytes + IV + ICV + padding.
For IPv6 Encrypted Payload content size is less than IP Datagram size In the case of IPv6, the content size of the Encrypted Payload is
by the sum of the following values: less than the IP datagram size by the sum of the following values:
o IPv6 header size (40 bytes) o IPv6 header size (40 bytes)
o IPv6 extension headers (optional, size varies) o IPv6 extension headers (optional; size varies)
o UDP header size (8 bytes) o UDP header size (8 bytes)
o non-ESP marker size (4 bytes if present) o non-ESP marker size (4 bytes if present)
o IKE Header size (28 bytes) o IKE header size (28 bytes)
o Encrypted Payload header size (4 bytes) o Encrypted payload header size (4 bytes)
o IV size (varying) o IV size (variable)
o padding and its size (at least 1 byte) o padding and its size (at least 1 byte)
o ICV size (varying) o ICV size (variable)
If no extension header is present, the sum may be estimated as 81..85 If no extension header is present, the sum may be estimated as
bytes + IV + ICV + padding. If extension headers are present, the 81..85 bytes + IV + ICV + padding. If extension headers are present,
payload content size is further reduced by the sum of the size of the the payload content size is further reduced by the sum of the size of
extension headers. The length of each extension header can be the extension headers. The length of each extension header can be
calculated as 8 * (Hdr Ext Len) bytes except for the fragment header calculated as 8 * (Hdr Ext Len) bytes, except for the fragment
which is always 8 bytes in length. header, which is always 8 bytes in length.
Acknowledgements
The author would like to thank Tero Kivinen, Yoav Nir, Paul Wouters,
Yaron Sheffer, Joe Touch, Derek Atkins, Ole Troan, and others for
their reviews and valuable comments. Thanks to Ron Bonica for
contributing text to the Introduction section. Thanks to Paul
Hoffman and Barry Leiba for improving text clarity.
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
Russian Federation Russian Federation
Phone: +7 495 276 0211 Phone: +7 495 276 0211
Email: svan@elvis.ru EMail: svan@elvis.ru
 End of changes. 157 change blocks. 
491 lines changed or deleted 518 lines changed or added

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