draft-ietf-ipsecme-ikev2-fragmentation-07.txt   draft-ietf-ipsecme-ikev2-fragmentation-08.txt 
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Intended status: Standards Track April 4, 2014 Intended status: Standards Track May 23, 2014
Expires: October 6, 2014 Expires: November 24, 2014
IKEv2 Fragmentation IKEv2 Fragmentation
draft-ietf-ipsecme-ikev2-fragmentation-07 draft-ietf-ipsecme-ikev2-fragmentation-08
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 do not 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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 6, 2014. This Internet-Draft will expire on November 24, 2014.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.1. Problem description . . . . . . . . . . . . . . . . . . . 3
2. Protocol details . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Proposed solution . . . . . . . . . . . . . . . . . . . . 3
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Conventions Used in This Document . . . . . . . . . . . . 4
2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol details . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Using IKE Fragmentation . . . . . . . . . . . . . . . . . 5 2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Fragmenting Message . . . . . . . . . . . . . . . . . . . 6 2.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 5
2.5.1. Selecting Fragment Size . . . . . . . . . . . . . . . 8 2.4. Using IKE Fragmentation . . . . . . . . . . . . . . . . . 6
2.5.2. PMTU Discovery . . . . . . . . . . . . . . . . . . . . 8 2.5. Fragmenting Message . . . . . . . . . . . . . . . . . . . 7
2.5.3. Fragmenting Messages containing unencrypted 2.5.1. Selecting Fragment Size . . . . . . . . . . . . . . . 9
Payloads . . . . . . . . . . . . . . . . . . . . . . . 10 2.5.2. PMTU Discovery . . . . . . . . . . . . . . . . . . . . 10
2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 10 2.5.3. Fragmenting Messages containing unprotected
2.6.1. Changes in Replay Protection Logic . . . . . . . . . . 12 Payloads . . . . . . . . . . . . . . . . . . . . . . . 11
3. Interaction with other IKE extensions . . . . . . . . . . . . 13 2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 12
4. Transport Considerations . . . . . . . . . . . . . . . . . . . 14 2.6.1. Replay Detection and Retransmissions . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 3. Interaction with other IKE extensions . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 4. Transport Considerations . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 22
Appendix B. Correlation between IP Datagram size and Appendix B. Correlation between IP Datagram size and
Encrypted Payload content size . . . . . . . . . . . 21 Encrypted Payload content size . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
1.1. Problem description
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. Most IKEv2 [IKEv2], 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 Noticeable exception is IKE_AUTH Exchange, which requires fairly
large messages, up to several kbytes, especially when certificates large messages, up to several kbytes, especially when certificates
are transferred. When IKE message size exceeds path MTU, it gets are transferred. When IKE message size exceeds path MTU, it gets
fragmented by IP level. The problem is that some network devices, fragmented by IP level. The problem is that some network devices,
specifically some NAT boxes, don't allow IP fragments to pass specifically some NAT boxes, do not allow IP fragments to pass
through. This apparently blocks IKE communication and, therefore, through. This apparently blocks IKE communication and, therefore,
prevents peers from establishing IPsec SA. prevents peers from establishing IPsec SA. Section 2 of [IKEv2]
discusses the impact of IP fragmentation on IKEv2 and acknowledges
this problem.
Widespread deployment of Carrier-Grade NATs (CGN) introduces new Widespread deployment of Carrier-Grade NATs (CGN) introduces new
challenges. RFC6888 [RFC6888] describes requirements for CGNs. It challenges. [RFC6888] describes requirements for CGNs. It states,
states, that CGNs must comply with Section 11 of RFC4787 [RFC4787], that CGNs must comply with Section 11 of [RFC4787], which requires
which requires NAT to support receiving IP fragments (REQ-14). In NAT to support receiving IP fragments (REQ-14). In real life
real life fulfillment of this requirement creates an additional fulfillment of this requirement creates an additional burden in terms
burden in terms of memory, especially for high-capacity devices, used of memory, especially for high-capacity devices, used in CGNs. It
in CGNs. It was found by people deploying IKE, that some ISPs have was found by people deploying IKE, that more and more ISPs use
begun to drop IP fragments, violating that requirement. equipment that drop IP fragments, violating this requirement.
Security researchers have found and continue to find attack vectors
that rely on IP fragmentation. For these reasons, and also
articulated in [FRAGDROP], many network operators filter all IPv6
fragments. Also, the default behavior of many currently deployed
firewalls is to discard IPv6 fragments.
In one recent study [BLACKHOLES], two researchers utilized a
measurement network to measure fragment filtering. They sent
packets, fragmented to the minimum MTU of 1280, to 502 IPv6 enabled
and reachable probes. They found that during any given trial period,
ten percent of the probes did not receive fragmented packets.
Thus this problem is valid for both IPv4 and IPv6 and may be caused
either by deficiency of network devices or by operational choice.
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 IKE itself, replacing them by fragmentation of large messages by IKEv2 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.
Avoiding IP fragmentation is beneficial for IKEv2 in general. The primary goal of this solution is to allow IKEv2 to operate in
Security Considerations Section of [RFC5996] mentions exhausting of environments, that may block IP fragments. This goal does not assume
the IP reassembly buffers as one of possible attacks on the protocol. that IP fragmentation should be avoided completely, but only in those
In the paper [DOSUDPPROT] several aspects of attacks on IKE using IP cases when it interferes with IKE operations. However this solution
fragmentation are discussed, and one of defenses it proposes is to could be used to avoid IP fragmentation in all situations where
perform IKE-level fragmentation, similar to the solution, described fragmentation within IKE is applicable, as it is recommended in
in this document. Section 3.2 of [RFC5405]. Avoiding IP fragmentation would be
beneficial for IKEv2 in general. Security Considerations Section of
[IKEv2] mentions exhausting of the IP reassembly buffers as one of
the possible attacks on the protocol. In the paper [DOSUDPPROT]
several aspects of attacks on IKE using IP fragmentation are
discussed, and one of the defenses it proposes is to perform
fragmentation within IKE similarly to the solution described in this
document.
1.1. 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 IKE message into a set of The idea of the protocol is to split large IKEv2 message into a set
smaller ones, called IKE Fragment Messages. Fragmentation takes of smaller ones, called IKE Fragment Messages. Fragmentation takes
place before the original message is encrypted and authenticated, so place before the original message is encrypted and authenticated, so
that each IKE Fragment Message receives individual protection. On that each IKE Fragment Message receives individual protection. On
the receiving side IKE Fragment Messages are collected, verified, the receiving side IKE Fragment Messages are collected, verified,
decrypted and merged together to get the original message before decrypted and merged together to get the original message before
encryption. For design rationale see Appendix A. encryption. See Appendix A for design rationale.
2.2. Limitations 2.2. Limitations
As 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 original
message can be fragmented if and only if it contains Encrypted message can be fragmented if and only if it contains Encrypted
Payload. 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, since 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 MODP Groups, etc.) these messages may become fairly large
and get fragmented by IP level. In this case the described solution and get fragmented by IP level. In this case the described solution
won't help. will not help.
Among existing IKEv2 extensions, messages of IKE_SESSION_RESUME Among existing IKEv2 extensions, messages of IKE_SESSION_RESUME
Exchange, defined in [RFC5723], cannot be fragmented either. See Exchange, 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 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 IPv4 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 indicates its support for the IKE Fragmentation and
willingness to use it by including Notification Payload of type willingness to use it by including Notification Payload of type
IKEV2_FRAGMENTATION_SUPPORTED in IKE_SA_INIT request message. If IKEV2_FRAGMENTATION_SUPPORTED in IKE_SA_INIT request message. If
Responder also supports this extension and is willing to use it, it Responder also supports this extension and is willing to use it, it
includes this notification in response message. includes this notification in response message.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SAi1, KEi, Ni, HDR, SAi1, KEi, Ni,
[N(IKEV2_FRAGMENTATION_SUPPORTED)] --> [N(IKEV2_FRAGMENTATION_SUPPORTED)] -->
skipping to change at page 5, line 28 skipping to change at page 6, line 28
| 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 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 IKEV2_FRAGMENTATION_SUPPORTED by IANA. for IKEV2_FRAGMENTATION_SUPPORTED notification.
This Notification contains no data. This Notification contains no data.
2.4. Using IKE Fragmentation 2.4. Using IKE Fragmentation
IKE Fragmentation MUST NOT be used unless both peers indicated their The IKE Fragmentation MUST NOT be used unless both peers have
support for it. After IKE Fragmentation is negotiated, it is up to indicated their support for it. After that it is up to the the
Initiator of each Exchange, whether to use it or not. In most cases Initiator of each exchange to decide whether to use it or not. The
IKE Fragmentation will be used in IKE_AUTH Exchange, especially if Responder usually replies in the same form as the request message,
certificates are employed. Initiator may first try to send but other considerations might override this.
unfragmented message and resend it fragmented only if it didn't
receive response after several retransmissions, or it may always send
messages fragmented (but see Section 3), or it may fragment only
large messages and messages causing large responses.
In general the following guidelines are applicable for initiator:
o Initiator MAY fragment outgoing message if it has some knowledge The Initiator may employ various policies regarding the use of IKE
(possibly from lower layer or from configuration) or suspicions Fragmentation. It may first try to send an unfragmented message and
that either request or response message will be fragmented by IP resend it as fragmented only if no complete response is received even
level. after several retransmissions. Alternatively, it may choose always
to send fragmented messages (but see Section 3), or it may fragment
only large messages and messages that are expected to result in large
responses.
o Initiator SHOULD fragment outgoing message if it has some The following general guidelines apply:
knowledge (possibly from lower layer or from configuration) or
suspicions that either request or response message will be
fragmented by IP level and IKE Fragmentation was already used in
one of previous Exchanges in the context of the current IKE SA.
o Initiator SHOULD NOT fragment outgoing message if both request and o If either peer has information that a part of the transaction is
response messages of the Exchange are small enough not to cause likely to be fragmented at the IP layer, causing interference with
fragmentation on IP level (for example, there is no point in the IKE exchange, that peer SHOULD use IKE Fragmentation. This
fragmenting Liveness Check messages). information may be passed from a lower layer, provided by
configuration, or derived through heuristics. Examples of
heuristics are the lack of a complete response after several
retransmissions for the Initiator, and receiving repeated
retransmissions of the request for the Responder.
In general the following guidelines are applicable for responder: 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
SHOULD continue the use of IKE Fragmentation for the messages that
are larger than the current fragmentation threshold (see
Section 2.5.1).
o Responder SHOULD send response message in the same form o IKE Fragmentation SHOULD NOT be used in cases where IP-layer
(fragmented or not) as corresponded request message. If it fragmentation of both the request and response messages is
received unfragmented request message, responded with unfragmented unlikely. For example, there is no point in fragmenting Liveness
response message and then receives fragmented retransmission of Check messages.
the same request, it SHOULD resend its response back to Initiator
fragmented.
o Responder MAY respond to unfragmented message with fragmented o If none of the above apply, the Responder SHOULD respond in the
response if it has some knowledge (possibly from lower layer or same form (fragmented or not) as the request message it is
from configuration) or suspicions that response message will be responding to. Note that the other guidelines might override this
fragmented by IP level. because of information or heuristics available to the Responder.
o Responder MAY respond to fragmented message with unfragmented In most cases IKE Fragmentation will be used in the IKE_AUTH
response if the size of the response message is less than the Exchange, especially if certificates are employed.
smallest fragmentation threshold, supported by Responder (for
example, there is no point in fragmenting Liveness Check
messages).
2.5. Fragmenting Message 2.5. Fragmenting Message
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 split into chunks. The content is content of Encrypted Payload is split into chunks. The content is
treated as a binary blob and is split regardless of inner Payloads treated as a binary blob and is split regardless of inner Payloads
boundaries. Each of resulting chunks is treated as an original boundaries. Each of resulting chunks is treated as an original
content of Encrypted Fragment Payload and is then encrypted and content of Encrypted Fragment Payload and is then encrypted and
authenticated. Thus, the Encrypted Fragment Payload contains a chunk authenticated. Thus, the Encrypted Fragment Payload contains a chunk
of the original content of Encrypted Payload in encrypted form. The of the original content of Encrypted Payload in encrypted form. The
cryptographic processing of Encrypted Fragment Payload is identical cryptographic processing of Encrypted Fragment Payload is identical
to Section 3.14 of [RFC5996], as well as documents updating it for to Section 3.14 of [IKEv2], as well as documents updating it for
particular algorithms or modes, such as [RFC5282]. particular algorithms or modes, such as [RFC5282].
The Encrypted Fragment Payload, similarly to the Encrypted Payload, The Encrypted Fragment Payload, similarly to the Encrypted Payload,
if present in a message, MUST be the last payload in the message. 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 XXX (TBA by IANA). This payload is also called the
"Encrypted and Authenticated Fragment" payload. "Encrypted and Authenticated Fragment" payload.
1 2 3 1 2 3
skipping to change at page 7, line 26 skipping to change at page 8, line 25
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 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 MUST be set to o Next Payload (1 octet) - in the very first fragment (with Fragment
Payload Type of the first inner Payload (similarly to the Number equal to 1) this field MUST be set to Payload Type of the
Encrypted Payload). In the rest fragments MUST be set to zero. first inner Payload (similarly to the Encrypted 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. This field MUST be less than or equal to the next field, Total 1. This field MUST be less than or equal to the next field, Total
Fragments. This field MUST NOT be zero. Fragments. This field MUST NOT be zero.
o Total Fragments (2 octets) - number of fragments original message o Total Fragments (2 octets) - number of fragments original message
was divided into. With PMTU discovery this field plays additional was divided into. This field MUST NOT be zero. With PMTU
role. See Section 2.5.2 for details. This field MUST NOT be discovery this field plays additional role. See Section 2.5.2 for
zero. 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
[RFC5996]. [IKEv2].
When prepending IKE Header, Length field MUST be adjusted to reflect When prepending IKE Header to the IKE Fragment Messages it MUST be
the length of constructed message and Next Payload field MUST reflect taken intact from the original message, except for the Length and the
payload type of the first Payload in the constructed message (that in Next Payload fields. The Length field is adjusted to reflect the
most cases will be Encrypted Fragment Payload). All newly length of the constructed message and the Next Payload field is set
constructed messages MUST retain the same Message ID as original to the payload type of the first Payload in constructed message (in
message. After prepending IKE Header and possibly any of Payloads most cases it will be Encrypted Fragment Payload). After prepending
that precedes Encrypted Payload in original message (see IKE Header and all Payloads that possibly precede Encrypted Payload
Section 2.5.3), the resulting messages are sent to the peer. in original message (if any, see 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 into chunks sender SHOULD chose When splitting content of Encrypted Payload into chunks sender SHOULD
size of those chunks so, that resulting IP Datagram size not exceed choose their size so, that resulting IP Datagrams be smaller than
some fragmentation threshold - be small enough to avoid IP some fragmentation threshold. Implementation may calculate
fragmentation. fragmentation threshold using various sources of information.
If sender has some knowledge about PMTU size it MAY use it. If If sender has information about PMTU size it SHOULD use it. The
sender is a Responder in the Exchange and it has received fragmented Responder in the exchange may use maximum size of received IKE
request, it MAY use maximum size of received IKE Fragment Message IP Fragment Message IP Datagrams as threshold when constructing
Datagrams as threshold when constructing fragmented response. fragmented response. Successful completion of previous exchanges
(including those exchanges, that cannot employ IKE Fragmentation,
e.g. IKE_SA_INIT) may be an indication, that fragmentation threshold
can be set to the size of the largest of already sent messages.
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 IP Datagram size ([RFC2460]). For value 1280 bytes as a maximum IP Datagram size ([RFC2460]). For
messages to be sent over IPv4 it is RECOMMENDED to use value 576 messages to be sent over IPv4 it is RECOMMENDED to use value 576
bytes as a maximum IP Datagram size. Presence of tunnels on the path bytes as a maximum IP Datagram size. Presence of tunnels on the path
may reduce these values. may reduce these values. Implementation may use other values if they
are appropriate in 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 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. Several other UDP-based protocol fragmentation in most situations. Several other UDP-based protocol
assume the value 576 bytes as a safe low limit for IP datagrams size assume the value 576 bytes as a safe low limit for IP datagrams size
(Syslog, DNS, etc.). Sender MAY use other values if they are (Syslog, DNS, etc.).
appropriate.
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
Initiator MAY try to discover path MTU by probing several values of The amount of traffic that IKE endpoint produces during lifetime of
fragmentation threshold. While doing probes, node MUST start from IKE SA is fairly modest - usually it is below one hundred kBytes
larger values and refragment message with next smaller value if it within a period of several hours. Most of this traffic consists of
doesn't receive response in a reasonable time after several relatively short messages - usually below several hundred bytes. In
retransmissions. This time is supposed to be relatively short, so most cases the only time when IKE endpoints exchange messages of
that node could make all desired probes before exchange times out. several kBytes in size is IKE SA establishment and often each
When starting new probe (with smaller threshold) node MUST reset its endpoint sends exactly one such message.
retransmission timers so, that if it employs exponential back-off,
the timers start over. After reaching the smallest allowed value for
fragmentation threshold implementation MUST continue probing using it
until either exchange completes or times out.
PMTU discovery in IKE is supposed to be coarse-grained, i.e. it is For the reasons atriculated above implementing PMTU discovery in IKE
expected, that node will try only few fragmentation thresholds, in is OPTIONAL. It is believed that using the values recommended in
order to minimize possible IKE SA establishment delay. In a corner Section 2.5.1 as fragmentation threshold will be sufficient in most
case, when host will use only one value, PMTU discovery will cases. Using these values could lead to suboptimal fragmentation,
effectively be disabled. In most cases PMTU discovery will not be but it is acceptable given the amount of traffic IKE produces.
needed, as using values, recommended in section Section 2.5.1, should Implementation may support PMTU discovery if there are good reasons
suffice. It is expected, that PMTU discovery may be useful in to do it (for example if it is intended to be used in environments
environments where PMTU size are smaller, than those listed in where MTU size is possible to be less that values listed in
Section 2.5.1, for example due to the presence of intermediate Section 2.5.1).
tunnels.
PMTU discovery in IKE follows recommendations, given in Section 10.4 PMTU discovery in IKE follows recommendations given in Section 10.4
of RFC4821 [RFC4821] with some differences, induced by the of [RFC4821] with the difference, induced by the specialties of IKE
specialties of IKE. In particular: listed above. The difference is that the PMTU search is performed
downward, while in [RFC4821] it is performed upward. The reason for
this change is that IKE usually sends large messages only when IKE SA
is being established and in many cases there is only one such
message. If the probing were performed upward this message would be
fragmented using the smallest allowable threshold, and usually all
other messages are small enough to avoid IP fragmentation, so there
would be little value to continue probing.
o Unlike classical PMTUD [RFC1191] and PLMTUD [RFC4821] the goal of It is the Initiator of the exchange, who performs PMTU discovery. It
Path MTU discovery in IKE is not to find the largest size of IP is done by probing several values of fragmentation threshold.
packet, that will not be fragmented en route, but to find any Implementation MUST be prepared to probe in every exchange that
reasonable size, probably far from optimal. utilizes IKE Fragmentation to deal with possible changes of path MTU
over time. While doing probes, it MUST start from larger values and
refragment original message using next smaller value of threshold if
it did not receive response in a reasonable time after several
retransmissions. The exact number of retransmissions and length of
timeouts are not covered in this specification because they do not
affect interoperability. However, the timeout interval is supposed
to be relatively short, so that unsuccessful probes would not delay
IKE operations too much. Performimg few retries within several
seconds for each probe seems appropriate, but different environments
may require different rules. When starting new probe node MUST reset
its retransmission timers so, that if it employs exponential back-
off, the timers will start over. After reaching the smallest allowed
value for fragmentation threshold implementation MUST continue
retransmitting until either exchange completes or times out using
timeout interval from Section 2.4 of [IKEv2].
o There is no goal to completely disallow IP fragmentation until its PMTU discovery in IKE is supposed to be coarse-grained, i.e. it is
presence leads to inability IKE to communicate (e.g. when IP expected, that node will try only few fragmentation thresholds, in
fragments are dropped) order to minimize delays caused by unsuccessful probes. If no
information about path MTU is known yet, endpoint may start probing
from link MTU size. In the following exchanges node should start
from the current value of fragmentation threshold.
o IKE usually sends large messages only in IKE_AUTH exchange, i.e. If implementation is capable to receive ICMP error messages it may
once per IKE SA. Most of other messages will have size below additionally utilize classic PMTU discovery methods, described in
several hundred bytes. Performing full PMTUD for sending exactly [RFC1191] and [RFC1981]. In particular, if the Initiator receives
one large message is inefficient. Packet Too Big error in response to the probe, and it contains
smaller value, than current fragmentation threshold, then the
Initiator SHOULD stop retransmitting the probe and SHOULD select new
value for fragmentation threshold that is less than or equal 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 case of PMTU discovery 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 obtained by fragmenting original message using different were created by fragmenting original message using different
fragmentation thresholds. As sender will start from larger fragments fragmentation thresholds. Since sender starts from larger fragments
and then make them smaller, the value in Total Fragments field will and then make them smaller, the value in Total Fragments field
increase with each new try. When selecting next smaller value of increases with each new probe. When selecting next smaller value for
fragmentation threshold, sender MUST ensure that the value in Total fragmentation threshold, sender MUST ensure that the value in Total
Fragments field is really increased. This requirement should not Fragments field is really increased. This requirement should not be
become a problem for the sender, as PMTU discovery in IKE is supposed a problem for the sender, because PMTU discovery in IKE is supposed
to be coarse-grained, so difference between previous and next to be coarse-grained, so difference between previous and next
fragmentation thresholds will be significant anyway. The necessity fragmentation thresholds should be significant anyway. The necessity
to distinguish between the sets is vital for receiver as receiving to distinguish between the sets is vital for receiver since receiving
any valid fragment from newer set will mean that it have to start valid fragment from newer set means that it have to start
reassembling over and not to mix fragments from different sets. reassembling over and not to mix fragments from different sets.
2.5.3. Fragmenting Messages containing unencrypted Payloads 2.5.3. Fragmenting Messages containing unprotected Payloads
Currently no one of IKEv2 Exchanges defines messages, containing both Currently there are no IKEv2 exchanges that define messages,
unencrypted payloads and payloads, protected by Encrypted Payload. containing both unprotected payloads and payloads, protected by
But IKEv2 doesn't forbid such messages. If some future IKEv2 Encrypted Payload. However IKEv2 does not prohibit such
extension defines such a message and it needs to be fragmented, all construction. If some future IKEv2 extension defines such a message
unprotected payloads MUST be in the first fragment, along with and it needs to be fragmented, all unprotected payloads MUST be
Encrypted Fragment Payload, which MUST be present in any IKE Fragment placed in the first fragment (with Fragment Number field equal to 1),
Message. along with Encrypted Fragment Payload, which MUST be present in every
IKE Fragment Message and be the last payload in it.
Below is an example of fragmenting message, containing both encrypted Below is an example of fragmenting message, containing both protected
and unencrypted Payloads. 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 very first, should not exceed fragmentation threshold, including the first one,
which contains unprotected Payloads. This will reduce the size of that contains unprotected Payloads. This will reduce the size of
Encrypted Fragment Payload content in the first IKE Fragment Message Encrypted Fragment Payload content in the first IKE Fragment Message
to accommodate unprotected Payloads. In extreme cases Encrypted to accommodate all unprotected Payloads. In extreme case Encrypted
Fragment Payload will contain no data, but it is still MUST be Fragment Payload will contain no data, but it still must be present
present in the message, because only its presence allows receiver to in the message, because only its presence allows receiver to
distinguish IKE Fragment Message from regular IKE message. determine that sender have used IKE Fragmentation.
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. In most cases it will be the first and the
to be not the first (and the only) payload in the message (see only payload in the message, however this may not be true for some
Section 2.5.3). But for all currently defined IKEv2 exchanges this hypothetical IKE exchanges (see Section 2.5.3)
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
are valid. The following tests need to be performed. are valid. The following tests need to be performed.
* check that Fragment Number and Total Fragments fields are non- * check that Fragment Number and Total Fragments fields are non-
zero zero
* check that Fragment Number field is less than or equal to Total * check that Fragment Number field is less than or equal to Total
Fragments field Fragments field
* if reassembling has already started, check that Total Fragments * if reassembling has already started, check that Total Fragments
field is equal to or greater than Total Fragments field in field is equal to or greater than Total Fragments field in
fragments, that have already received fragments that have already been stored in the reassembling
queue
If any of this tests fails message MUST be silently discarded. If any of this tests fails 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 IKE Fragment message with the same Message ID,
same Fragment Number and same Total Fragments fields was already same Fragment Number and same Total Fragments fields is already
received and successfully processed, this message is considered a present in the reassembling queue, this message is considered a
replay and MUST be silently discarded. replay and MUST be silently 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 If reassembling isn't finished yet and Total Fragments field in o If reassembling is not finished yet and Total Fragments field in
received IKE Fragment Message is greater than this field in received fragment is greater than this field in those fragments,
previously received fragments, receiver MUST discard all received that are in the reassembling queue, receiver MUST discard all
fragments and start reassembling over with just received IKE received fragments and start reassembling over with just received
Fragment Message. IKE Fragment Message.
o Store message in the list waiting for the rest of fragments to o Store message in the reassembling queue waiting for the rest of
arrive. 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, content of their already decrypted Encrypted field) are received, decrypted content of all Encrypted Fragment
Fragment Payloads is merged together to form content of original Payloads is merged together to form content of original Encrypted
Encrypted Payload, and, therefore, along with IKE Header and Payload, and, therefore, along with IKE Header and unprotected
unencrypted Payloads (if any), original message. Then it is Payloads (if any), original message. Then it is processed as if it
processed as if it was received, verified and decrypted as regular was received, verified and decrypted as regular IKE message.
unfragmented message.
If receiver doesn't get all IKE Fragment Messages needed to If receiver does not get all IKE fragments needed to reassemble
reassemble original Message for some Exchange within a timeout original Message within a timeout interval, it MUST discard all
interval, it acts according with Section 2.1 of [RFC5996], i.e. received so far IKE Fragment Messages for the exchange. Next actions
depend on the role of receiver in the exchange.
retransmits the fragmented request Message (in case of Initiator) or o The Initiator acts as described in Section 2.1 of [IKEv2]. It
deems Exchange to have failed. If Exchange is abandoned, all either retransmits the fragmented request Message or deems IKE SA
received so far IKE Fragment Messages for that Exchange MUST be to have failed and deletes it. The number of retransmits and
discarded. length of timeouts for the Initiator are not covered in this
specification since they are assumed to be the same as in regular
IKEv2 exchange and are discussed in Section 2.4 of [IKEv2].
2.6.1. Changes in Replay Protection Logic o The Responder in this case acts as if no request message was
received. The reassembling timeout for Responder is RECOMMENDED
to be equal to the time interval that implementation waits before
completely giving up when acting as Initiator of exchange.
Section 2.4 of [IKEv2] gives recommendations for selecting this
interval. Implementation MAY use shorter timeout to conserve
memory.
According to [RFC5996] IKEv2 MUST reject message with the same 2.6.1. Replay Detection and Retransmissions
According to [IKEv2] implementation 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 zero Message ID. 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 for the situations, when IKE
Fragment Payload, the values of Fragment Number and Total Fragments Fragmentation is in use.
fields from this payload MUST be used along with Message ID to detect
retransmissions and replays.
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 If incomimg message contains Encrypted Fragment Payload, the values
reassembled, verified and processed fragmented message, it MUST of Fragment Number and Total Fragments fields MUST be used along with
retransmit response back to Initiator, but only if Fragment Number Message ID to detect retransmissions and replays.
field in Encrypted Fragment Payload is equal to 1 and MUST silently
discard received message otherwise. If Total Fragments field in
received IKE Fragment Message is greater than in IKE Fragment
Messages that already processed fragmented message was reassembled
from, Responder MAY refragment its response message using smaller
fragmentation threshold before resending it back to Initiator. In
this case Total Fragments field in new IKE Fragment Messages MUST be
greater than in previously sent IKE Fragment Messages.
If Initiator doesn't receive any of response IKE Fragment Messages If Responder receives retransmitted fragment of request when it has
within a timeout interval, it MAY refragment request Message using already processed that request and has sent back a response, that
smaller fragmentation threshold before retransmitting it (see event MUST only trigger retransmission of the response message
Section 2.5.1). In this case Total Fragments field in new IKE (fragmented or not) if Fragment Number field in received fragment is
Fragment Messages MUST be greater than in previously sent IKE set to 1 and MUST be ignored otherwise.
Fragment Messages. Alternatively, if Initiator does receive some
(but not all) of response IKE Fragment Messages, it MAY retransmit
only the first of request IKE Fragment Messages, where Fragment
Number field is equal to 1.
3. Interaction with other IKE extensions 3. Interaction with other IKE extensions
IKE Fragmentation is compatible with most of defined IKE extensions, IKE Fragmentation is compatible with most of IKE extensions, such as
like IKE Session Resumption [RFC5723], Quick Crash Detection Method IKE Session Resumption ([RFC5723]), Quick Crash Detection Method
[RFC6290] and so on. It neither affect their operation, nor is ([RFC6290]) and so on. It neither affect 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 most 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,
described in [RFC5996]. described in [IKEv2].
When IKE Fragmentation is used with IKE Session Resumption [RFC5723], When IKE Fragmentation is used with IKE Session Resumption
messages of IKE_SESSION_RESUME Exchange cannot be fragmented as they ([RFC5723]), messages of IKE_SESSION_RESUME Exchange cannot be
don't contain Encrypted Payload. These messages may be large due to fragmented since they do not contain Encrypted Payload. These
ticket size. If this is the case the described solution won't help. messages may be large due to the ticket size. To avoid IP
To avoid IP Fragmentation in this situation it is recommended to use Fragmentation in this situation it is recommended to use smaller
smaller tickets, e.g. by utilizing "ticket by reference" approach tickets, e.g. by utilizing "ticket by reference" approach instead of
instead of "ticket by value". "ticket by value".
One exception that requires a special care is [RFC6311] - Protocol One exception that requires a special care is Protocol Support for
Support for High Availability of IKEv2. As it deliberately allows High Availability of IKEv2/IPsec ([RFC6311]). Since it deliberately
any number of synchronization Exchanges to have the same Message ID - allows any number of synchronization exchanges to have the same
zero, standard replay detection logic, based on checking Message ID Message ID, namely zero, standard IKEv2 replay detection logic, based
is not applicable for such messages, and receiver has to check on checking Message ID is not applicable for such messages, and
message content to detect replays. When implementing IKE receiver has to check message content to detect replays. When
Fragmentation along with [RFC6311], IKE Message ID Synchronization implementing IKE Fragmentation along with [RFC6311], IKE Message ID
messages MUST NOT be sent fragmented to simplify receiver's task of Synchronization messages MUST NOT be sent fragmented to simplify
detecting replays. Fortunately, these messages are small and there receiver's task of detecting replays. Fortunately, these messages
is no point in fragmenting them anyway. 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 get lost,
receiver becomes unable to reassemble original Message. So, in receiver becomes unable to reassemble original Message. So, in
general, using IKE Fragmentation implies higher probability for the general, using IKE Fragmentation implies higher probability for the
Message not to be delivered to the peer. Although in most network Message not to be delivered to the peer. Although in most network
environments the difference will be insignificant, on some lossy environments the difference will be insignificant, on some lossy
networks it may become noticeable. When using IKE Fragmentation networks it may become noticeable. When using IKE Fragmentation
implementations MAY use longer timeouts and do more retransmits implementations MAY use longer timeouts and do more retransmits than
before considering peer dead. usual before considering 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 sent back all together only when all
fragments of request are received, the original request Message is fragments of request are received, the original request Message is
reassembled and successfully processed. 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 base IKEv2 protocol described in [RFC5996]. This same as those for the base IKEv2 protocol described in [IKEv2]. 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 peers from DoS attack. authenticity of fragments, thus protecting peers from DoS attack.
Security Considerations Section of [RFC5996] mentions possible attack Security Considerations Section of [IKEv2] mentions possible attack
on IKE by exhausting of the IP reassembly buffers. The mechanism, on IKE by exhausting of the IP reassembly buffers. The mechanism,
described in this document, allows IKE to avoid IP-fragmentation and 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 IKE_SA_INIT Exchange, complete it, compute SK_a and SK_e
and then send a large, but still incomplete, set of IKE_AUTH 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 as 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
receiver limits the number of fragments it stores in reassembling receiver limits the number of fragments it stores in 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 reassembling queue be less than some value that is reasonable into the reassembling queue be less than some value that is
for the implementation. If the peer sends so many fragments, that reasonable for the implementation. If the peer sends so many
the above condition is not met, the receiver can consider this fragments, that the above condition is not met, the receiver can
situation to be either attack or as broken sender implementation. In consider this situation to be either attack or as broken sender
either case, the receiver SHOULD drop the connection and discard all implementation. In either case, the receiver SHOULD drop the
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 receiver's memory load. In any calculated dynamically depending on receiver's memory load. In any
case, the value SHOULD NOT exceed 64 Kbytes (the maximum size of UDP case, the value SHOULD NOT exceed 64 Kbytes (the maximum size of UDP
datagram) because any IKE message before fragmentation must be datagram) because any IKE message before fragmentation must be
shorter than that. shorter than that.
6. IANA Considerations 6. IANA Considerations
This document defines new Payload in the "IKEv2 Payload Types" This document defines new Payload in the "IKEv2 Payload Types"
skipping to change at page 17, line 8 skipping to change at page 19, line 8
<TBA> Encrypted and Authenticated Fragment SKF <TBA> Encrypted and Authenticated Fragment SKF
This document also defines new Notify Message Types in the "Notify This document also defines new Notify Message Types in the "Notify
Message Types - Status Types" registry: Message Types - Status Types" registry:
<TBA> IKEV2_FRAGMENTATION_SUPPORTED <TBA> IKEV2_FRAGMENTATION_SUPPORTED
7. Acknowledgements 7. Acknowledgements
The author would like to thank Tero Kivinen, Yoav Nir, Paul Wouters, The author would like to thank Tero Kivinen, Yoav Nir, Paul Wouters,
Yaron Sheffer, Joe Touch, Derek Atkins and others for their reviews Yaron Sheffer, Joe Touch, Derek Atkins, Ole Troan and others for
and valuable comments. 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 8. References
8.1. Normative References 8.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, [IKEv2] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
"Internet Key Exchange Protocol Version 2 (IKEv2)", Kivinen, "Internet Key Exchange Protocol Version 2
RFC 5996, September 2010. (IKEv2)", draft-kivinen-ipsecme-ikev2-rfc5996bis-03 (work
in progress), April 2014.
[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.
8.2. Informative References 8.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.
[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.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[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.
[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.
[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.
[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.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
November 2008.
[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.
[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.
[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.
[FRAGDROP]
Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
M., and T. Taylor, "Why Operators Filter Fragments and
What It Implies", draft-taylor-v6ops-fragdrop-02 (work in
progress), December 2013.
[BLACKHOLES]
De Boer, M. and J. Bosma, "Discovering Path MTU black
holes on the Internet using RIPE Atlas", July 2012, <http:
//www.nlnetlabs.nl/downloads/publications/
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 the IKE fragmentation would have been to
fragment message that is fully formed and ready to be sent. But if fragment message that is fully formed and ready to be sent. But if
message got fragmented after being encrypted and authenticated, this message got fragmented after being encrypted and authenticated, this
 End of changes. 84 change blocks. 
287 lines changed or deleted 353 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/